# git におけるコミット署名ベストプラクティス調査結果
## 改訂履歴
| 版 | 日付 | 改訂内容 |
|---|---|---|
| 1.0 | 2026-06-04 | 初版作成 |
---
## 0. 本調査の前提
### 0.1 調査の目的と段階
「git におけるコミット署名のベストプラクティス」として、Web 上で語られている見解と、学術研究で実証されている実態を、事実情報として整理する。本レポートは**事実情報の収集とまとめの段階**であり、規範論的な提言や考察は最小限にとどめる。
> **【筆者注記】利害関係の開示**
> 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。
> 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。
> **本記事の作成プロセス**
> 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。
### 0.2 調査の範囲
調査対象は以下：
- 公式ドキュメント：GitHub Docs、Git 公式ドキュメント、Yubico Developer Docs
- 技術ブログ：個人ブログ、商用ベンダーブログ等
- コミュニティ議論：GitHub Issues、GitLab Issues 等
- 学術研究：arXiv に公開された定量的研究
### 0.3 用語の整理
| 用語 | 意味 |
|---|---|
| コミット署名 | `git commit` に暗号学的署名を付与すること |
| GPG 署名 | GnuPG（OpenPGP 実装）を用いた署名 |
| SSH 署名 | OpenSSH の `ssh-keygen -Y sign` 機能を用いた署名 |
| S/MIME 署名 | X.509 証明書を用いた署名方式（組織向け） |
| Verified バッジ | GitHub 等が署名検証成功時に表示する印 |
| Vigilant Mode | GitHub の機能、Author 名と署名状態の不一致を可視化 |
---
## 1. なぜコミットに署名するのか（技術的事実）
### 1.1 Git の Author 情報には暗号学的担保がない
Git では、`user.name` と `user.email` を任意の値に設定できる。これは Git の柔軟な設計の一部だが、副作用として「**第三者が他人を装ったコミットを作成可能**」という構造を生む。
技術的には以下のような操作が可能である：
```bash
git config user.name "Alice"
git config user.email "
[email protected]"
git commit -m "コードの変更"
```
実際の作者が Bob であっても、Git の Author 行は Alice として記録される。署名がなければ、これを暗号学的に区別する手段はない。
### 1.2 署名が担保する三つの性質
コミット署名は、以下を担保する：
- **作者の真正性**：このコミットは確かに特定の秘密鍵を持つ者が作成した
- **改ざんの不在**：コミット作成後、内容が変更されていない（暗号学的ハッシュとの結合）
- **非否認性**：署名は当該秘密鍵でしか生成できないため、作者が後に「自分が作成していない」と主張しても、その否認が困難になる
### 1.3 GitHub プラットフォームでの可視化
GitHub は、検証可能な署名を持つコミットに「**Verified**」バッジを表示する[^1]。これにより、リポジトリの閲覧者は、コミットの暗号学的な真正性を視覚的に確認できる。
---
## 2. 学術研究で実証された実態
### 2.1 研究 1：60 リポジトリの 5 年間分析
Sharma らによる arXiv 2504.19215（2025 年 4 月）は、GitHub の主要リポジトリにおけるコミット署名の実態を、5 年間（2020-2024）にわたり分析した[^2]。
#### 調査対象
- 60 のオープンソースリポジトリ
- 4 ドメイン × 15 リポジトリずつ：Web 開発、データベース、機械学習、セキュリティ
- GitStar Ranking で各ドメインの上位リポジトリを選定
- 2020 年 4 月から 2024 年 12 月までのコミットを分析
#### 主要な発見
> only ~10% of all the commits in these 60 repositories are verified.
（参考訳：これら 60 リポジトリの全コミットのうち、検証済みのものは約 10% に過ぎない。）
**主要 OSS リポジトリでも、全コミットの約 10% しか検証済み（Verified）ではない**。
ドメイン別の内訳：
| ドメイン | Verified コミットの割合 |
|---|---|
| セキュリティ関連 | 28.35% |
| Web 開発 | 12.77% |
| データベース | 5.95% |
| 機械学習 | 2.55% |
セキュリティ関連リポジトリが、他のドメインを大きく上回る。論文は次のように述べる：
> Developers committing code to security-related repositories are much more vigilant when it comes to signing commits by users.
（参考訳：セキュリティ関連リポジトリにコードをコミットする開発者は、コミット署名に関してはるかに注意深い。）
#### Vigilant Mode 導入後の経時変化
GitHub の Vigilant Mode 導入後、署名コミットの使用は最初の 1 年で増加したが、その後は減少傾向にある、と論文は報告している。
### 2.2 研究 2：エコシステム規模の開発者中心分析
Shittu らによる arXiv 2604.14014（2026 年 4 月）は、より大規模かつ開発者中心の分析を行った[^3]。
#### 調査対象
- 71,694 人の active 開発者
- 1,610 万コミット
- 874,198 リポジトリ
- GitHub プラットフォーム全体の履歴を網羅
#### 主要な発見 1：見かけの署名率と実態の乖離
> overall signing adoption rates are misleading, as most signed commits come from automatic platform signing rather than deliberate developer action
（参考訳：全体的な署名の採用率は誤解を招くものである。なぜなら、署名されたコミットの大半は、開発者の意図的な行動ではなく、プラットフォームによる自動署名から生じているからである。）
**「Verified」表示されたコミットの大半は、GitHub Web UI 経由の自動署名（GitHub の web-flow 鍵による署名）であり、開発者が能動的に署名したものではない**、と論文は報告している。
具体的な数値：
- 全体としての署名率（GitHub UI 経由の自動署名を含む）：**24.05%**（論文 Table 3、2% コホート）
- 一方、署名済みコミットのうち **82.69%** は GitHub UI 経由の自動署名（論文 §5）
- 非 UI コミットを 1 件以上行ったユーザー 61,364 人のうち、ローカル鍵で署名を行ったことのあるユーザーは **5.94%（3,643 人）** のみ（論文 §6）
論文の序論（Introduction）には、以下の表現がある：
> once these are excluded, only a vanishingly small fraction of all developers have ever signed with a locally held key
（参考訳：これら（プラットフォーム生成の署名）を除くと、ローカル保持の鍵で署名したことのある開発者は、消滅レベルに小さい割合に過ぎない。）
#### 主要な発見 2：署名の継続性
> developers who do sign locally rarely keep it up consistently across repositories or over time
（参考訳：ローカルで署名する開発者でも、複数のリポジトリにわたって、あるいは時間を超えて、署名を一貫して続けることは稀である。）
**ローカル鍵で署名する少数の開発者でも、リポジトリや時間を超えて一貫して署名を継続することは稀**。
中断率（lapse rate）に関する観察：
- 開発者間の中断率は、アカウント年齢が高くなるほど上昇
- ローカル署名を行う開発者（3,643 人）のうち、12.65%（461 人）のみが、関わる全リポジトリで一貫して署名
- 同じく 87.32%（3,181 人）の開発者は、リポジトリによって署名したりしなかったり
### 2.3 二つの研究の総合的観察
両研究を総合すると、以下の事実が確認できる：
1. **コミット署名は、OSS 界隈の多数派の実践ではない**：主要リポジトリでも約 10%
2. **見かけの署名率には GitHub Web UI 自動署名が含まれる**：非 UI コミットを行ったユーザーに限ると、ローカル鍵で能動的に署名するユーザーは 5.94% のみ
3. **ドメイン依存性が強い**：セキュリティ分野が突出、機械学習分野は極めて低い
4. **継続性に課題**：始めても継続が難しい
---
## 3. 署名運用が確立されている事例：Linux カーネル
§2 で確認した通り、OSS 全体ではコミット署名の採用は限定的である。一方で、特定のプロジェクトでは独自の署名運用が確立されている。本節では、その代表例として Linux カーネル開発コミュニティの運用を整理する。
### 3.1 Linux カーネルの「署名」の三層構造
Linux カーネルの開発プロセスにおける「署名」は、複数の異なる仕組みが併存する：
#### 第一層：DCO（Developer Certificate of Origin）と Signed-off-by 行
これは**暗号学的署名ではなく、法的な権利表明**である[^23]：
- 2004 年に SCO 訴訟への対応として導入
- コミットメッセージに `Signed-off-by: Real Name <
[email protected]>` という行を追加
- 開発者は、developercertificate.org に記載された条項に同意することを表明
- 「自分がコードを書いた、または書く権利を持つ者から受け取った」ことを証明する法的宣言
- カーネルへの全コミットで必須
- 既知のアイデンティティ（known identity）を使用すること、匿名は不可（かつては実名必須・仮名不可とされていたが、現行のカーネル文書では「既知のアイデンティティ」要件に緩和されている）
カーネル公式ドキュメント "SubmittingPatches" は、2006 年に Greg Kroah-Hartman らによる以下のパッチで、匿名禁止を明示している[^24]（なお同パッチで追加された「実名必須」の文言は、その後の改訂で現行の「既知のアイデンティティ」要件に緩和されている）：
> The DCO does not mean anything if we allow anonymous contributors to the kernel. As this is an open source project, we need to do everything in the open.
（参考訳：匿名の貢献者を許可するなら、DCO は意味を持たない。これはオープンソースプロジェクトであり、すべてを公開で行う必要がある。）
#### 第二層：プルリクエストの PGP 署名タグ
サブシステムメンテナーから上位メンテナー（最終的には Linus Torvalds）へのプルリクエストには、**git tag への PGP 署名**が用いられる[^25][^26]：
- サブシステムメンテナーが、ブランチの先端に署名付きタグを作成
- プル要求時に、署名付きタグを送る
- 受け取り側が `git verify-tag` で署名を検証
- これにより、「**このプル要求は確かにそのメンテナーから来た**」を担保
Linus Torvalds 自身は、署名タグについて以下のように述べている[^27]：
> I don't require signed tags for kernel.org pulls, but I really do heavily prefer them, and they aren't that hard to do.
（参考訳：kernel.org のプルに対して、署名タグを必須とはしていないが、強く好む。難しいものでもない。）
つまり、Linux カーネルの公式ポリシーとして、**kernel.org リポジトリからのプル要求については、署名タグは「必須」ではなく「強く推奨」**である。ただし、これは kernel.org からのプル要求に限った話であり、カーネル公式文書には「Linus は GitHub 等の公開ホスティングサイトからのプル要求については、署名タグなしでは受け付けない」旨が明記されている。つまり、**外部ホスト（GitHub 等）からのプル要求では署名タグは事実上必須**である。
#### 第三層：個別コミットへの PGP 署名
カーネル公式の "Kernel Maintainer PGP guide" は、個別コミットへの PGP 署名を推奨している[^25]：
> Signed tags prove the repository integrity by assuring that its contents are exactly the same as on the workstation of the developer who created the tag, while signed commits make it nearly impossible for someone to impersonate you without having access to your PGP keys.
（参考訳：署名付きタグは、リポジトリの内容がタグを作成した開発者のワークステーション上のものと完全に同一であることを保証することで、リポジトリの完全性を証明する。一方、署名付きコミットは、PGP 鍵にアクセスできない者があなたを偽装することをほぼ不可能にする。）
しかし、ガイドは同時に、構造的な制約も指摘している[^25]：
> The kernel contribution workflow relies on sending in patches, and converting commits to patches does not preserve git commit signatures. Furthermore, when rebasing your own repository on a newer upstream, PGP commit signatures will end up discarded.
（参考訳：カーネルの貢献ワークフローはパッチを送ることに依拠しており、コミットをパッチに変換すると git コミット署名は保持されない。さらに、自分のリポジトリを新しい上流に rebase すると、PGP コミット署名は破棄される結果となる。）
つまり、Linux カーネルの**パッチベースワークフローは、構造的に個別コミット署名と相性が悪い**。これが、コミット署名ではなくタグ署名が中心となる理由である。
### 3.2 kernel.org の PGP 鍵リポジトリ運営
公開鍵サーバー（key server）が広範な攻撃を受けて事実上機能停止したことに対応し、Linux カーネルコミュニティは独自の公開鍵管理基盤を運営している[^26][^28]：
- Konstantin Ryabitsev が、カーネル開発者の公開鍵を集約した git リポジトリ（korg-pgpkeys）を運営
- 鍵を追加するには、**リポジトリ内の既存鍵から署名を受けており、Linus Torvalds の鍵まで trust path を辿れること**が要件
- 信頼の輪は、2011 年の Kernel Summit でのキーサイニングセッションでブートストラップされた
LWN.net の記事は、この運営の意義を以下のように述べている[^28]：
> A Git repository full of keys will not solve the world's authentication problems, but it may well prove sufficient for the task of keeping kernel pull requests secure.
（参考訳：鍵で満たされた git リポジトリは、世界の認証問題を解決するものではないが、カーネルのプル要求を安全に保つという目的には十分かもしれない。）
これは、**特定の規模・特定の文脈での Web of Trust の現実的運用**の事例である。一般化されたインターネット規模では機能しない PGP Web of Trust が、Linux カーネル開発コミュニティのような相対的に閉じたコミュニティでは機能している。
### 3.3 運用上の論点
Linus Torvalds 自身の発言からは、PGP 運用の困難も読み取れる。2022 年のあるプルリクエスト議論で、彼は次のように述べている[^29]：
> Oh, how I hate pgp. I thought that having git wrap all the key verification would make it usable (counter-example: the incredible garbage that is pgp signed email), but then the keyservers stopped working, and so the keys themselves end up being a problem.
（参考訳：ああ、PGP は本当に嫌いだ。git がすべての鍵検証を包んでくれれば使えるものになると思っていた（反例：PGP 署名されたメールという信じがたい混乱）が、その後キーサーバーが機能しなくなり、結局鍵自体が問題となった。）
これは、Linux カーネルの中心的人物ですら、PGP 運用の困難を公言する状況を示している。にもかかわらず、カーネルコミュニティが PGP 署名タグ運用を継続しているのは、それを上回る価値があると判断されているためと考えられる。
### 3.4 Linux カーネルの事例から得られる事実観察
以下は、Linux カーネルの運用から得られる事実観察である：
1. **「コミット署名を励行」と一括することはできない**：DCO（Signed-off-by）、タグ署名、個別コミット署名は別のものであり、それぞれ異なる意義と必須度を持つ
2. **必須なのは DCO（Signed-off-by）のみ**：これは法的表明であり、暗号学的署名ではない
3. **強く推奨されるのはタグ署名**：個別コミット署名は推奨に留まる
4. **パッチベースワークフローと個別コミット署名は相性が悪い**：構造的に署名が維持できない
5. **独自の Web of Trust 管理基盤を運営**：korg-pgpkeys repository、Linus Torvalds を起点とする trust path
6. **特定コミュニティ規模での Web of Trust は機能しうる**：インターネット全体には拡張困難だが、閉じたコミュニティでは実用的
---
## 4. 業界の三つの選択肢：GPG、SSH、S/MIME
### 4.1 GitHub Docs の公式見解
GitHub Docs の "About commit signature verification" は、選択肢を以下のように整理している[^1]：
> For most individual users, GPG or SSH will be the best choice for signing commits. S/MIME signatures are usually required in the context of a larger organization. SSH signatures are the simplest to generate.
（参考訳：ほとんどの個人ユーザーにとって、コミット署名には GPG または SSH が最良の選択となる。S/MIME 署名は、通常、より大規模な組織の文脈で必要とされる。SSH 署名は、生成が最も簡単である。）
つまり：
- **個人利用**：GPG または SSH
- **組織利用（特に大企業）**：S/MIME も選択肢
- **導入の容易さ**：SSH が最も簡単
### 4.2 各方式の特徴（事実情報）
#### GPG（GnuPG / OpenPGP）
- 最も歴史が長く、対応ツール・ホスティングサービスが広範
- Web of Trust（信頼の輪）と呼ばれる分散的な信頼モデルを持つ
- 鍵の用途別副鍵（署名用 [S]、認証用 [A]、暗号化用 [E]）が標準
- 公開鍵に UID（名前・メールアドレス）が埋め込まれる
- 設定は SSH より複雑で、学習コストが高い
#### SSH 署名
- OpenSSH 8.1（2019 年 10 月）で実験的な軽量署名機能（`ssh-keygen -Y sign`）が追加[^4]
- Git 2.34（2021 年 11 月）で SSH 署名対応が追加
- 既存の SSH 認証鍵を流用可能
- 鍵と identity の紐付けは、外部の `allowed_signers` ファイルで定義
- 設定は GPG より比較的シンプル
#### S/MIME
- X.509 証明書（PKI）に基づく署名
- 認証局（CA）の発行する証明書を使用
- 組織内 CA、または公的 CA から発行
- エンタープライズ環境での電子メール署名と同じインフラを利用可能
- 個人利用には設定負荷が高い
### 4.3 技術ブログでの議論傾向
技術ブログ・コミュニティ議論は、SSH 署名への移行を推す論調がある[^6][^7]。主な理由：
- 既存の SSH 鍵を流用できる
- 設定がシンプル
- ssh-agent が成熟している
ただし、これらの議論は技術ブログ著者の見解であり、§2 で確認した実態（OSS 全体での署名率の低さ）とは別の話である。
---
## 5. Key Separation Principle（鍵の用途分離原則）
### 5.1 原則の定義
**Key Separation Principle**（鍵の用途分離原則）は、暗号学・情報セキュリティの基本原則の一つで、「**異なる目的のためには、異なる暗号鍵を使うべき**」とする原則である。
### 5.2 原則の根拠
この原則が重要視される理由：
#### 攻撃面の分離
ある用途で鍵が漏洩した場合、他の用途への影響を限定するため。例えば、認証用と署名用が同じ鍵なら、認証経路で鍵が漏洩した際に、署名経路にも影響が及ぶ。
#### 監査の独立性
鍵の使用ログを、用途別に独立して追跡できる。同じ鍵で複数用途を兼ねると、ログから用途を判別できない。
#### 失効の独立性
特定の用途で問題が発生した場合、その用途の鍵だけを失効・更新できる。鍵を使い回していると、一つの失効が他用途にも波及する。
#### プロトコル間の干渉防止
異なる暗号プロトコル（認証プロトコルと署名プロトコル）が同じ鍵を使うことで、想定外の相互作用や攻撃（cross-protocol attack）が発生する可能性がある。
### 5.3 GPG における用途分離
GPG（OpenPGP）は、設計の段階から用途別に副鍵を分離する構造を持つ：
```
主鍵 [C] Certification（他鍵の認証、自己署名）
├ 副鍵 [S] Signing（コミット署名、文書署名）
├ 副鍵 [A] Authentication（SSH 認証等）
└ 副鍵 [E] Encryption（暗号化）
```
これは Key Separation Principle の構造的実装である。
### 5.4 SSH 署名の場合
OpenSSH では、認証用に生成した鍵をそのまま署名にも使うことが、技術的に可能である。実際、技術ブログの多くがこの流用を「利点」として紹介している。
ただし、これは Key Separation Principle の観点では、用途分離が成立しないことを意味する。SSH でも、認証用と署名用で別の鍵を生成することは技術的に可能だが、業界の慣行としては流用が一般的である。
---
## 6. リポジトリの自己完結性
### 6.1 PGP 公開鍵の自己記述性
PGP 公開鍵には、以下の情報が**鍵自体に埋め込まれている**：
- 公開鍵本体
- User ID（名前、メールアドレス）
- 作成日、有効期限
- 自己署名（鍵の内部整合性の証明）
- 副鍵情報
- 他者からの署名（Web of Trust の証拠）
公開鍵を取得した検証者は、「**この鍵は誰のものか**」の情報を、鍵自体から読み取れる。
### 6.2 SSH 公開鍵の構造
SSH 公開鍵には、以下しか含まれない：
- 公開鍵本体
- 鍵の種別
- オプションのコメント（自由記述）
UID という概念がプロトコルに存在しない。「**誰の鍵か**」を識別する仕組みは、鍵の外側（`allowed_signers` ファイル等）にある。
### 6.3 検証時の差異
**PGP 署名の検証**：
公開鍵を入手すれば、後の検証はローカルで完結する。
**SSH 署名の検証**：
`allowed_signers` ファイルの事前準備が必要。検証は「リポジトリ + 公開鍵 + 外部ファイル」のセットで成立する。
### 6.4 GitHub への依存
現実として、SSH 署名の検証は、GitHub の Verified バッジへの参照に依存していると見られる。これは、`allowed_signers` を手動で整備してまで独立検証するよりも、手軽に検証できるからであると見ることが出来る。
---
## 7. ハードウェアトークンによる秘密鍵保護
### 7.1 「秘密鍵がディスクに存在しないこと」の意味
複数の情報源が、署名鍵をハードウェアトークン（YubiKey、OpenPGP カード等）に格納することを推奨している[^8][^9]。技術的根拠：
- 秘密鍵がディスク上のファイルとして存在する限り、マルウェア・盗難・誤コミット等のリスクが残る
- ハードウェアトークンでは、秘密鍵が物理的にデバイスから取り出せない設計
- 署名操作はデバイス内で完結し、物理的なタッチや PIN 入力で意図確認が行われる
### 7.2 主な選択肢
- **YubiKey 5 シリーズ**：OpenPGP、PIV、FIDO2、OTP 等の多機能対応
- **OpenPGP カード（ZeitControl、Nitrokey 等）**：OpenPGP 規格に基づく専用カード
- **その他 FIDO2 対応デバイス**：OpenSSH 8.2+（2020 年 2 月）の `ed25519-sk` / `ecdsa-sk` 鍵タイプ用[^10]
### 7.3 Yubico の FIDO2 SSH 鍵推奨
Yubico の公式ガイドは、最新の推奨として FIDO2 SSH 鍵を挙げている[^11]：
- 秘密鍵は YubiKey 内に保持
- 物理タッチで署名意図を確認
- FIDO2 プロトコルで動作（PKCS#11 経路を経由しない）
---
## 8. Sigstore / cosign：keyless 署名
### 8.1 Sigstore とは
Sigstore（および中核ツールの cosign、gitsign）は、近年のソフトウェアサプライチェーンセキュリティのプロジェクトである。Linux Foundation のプロジェクトとして開発されている[^12]。
特徴：
- 「**keyless 署名**」：長期的な秘密鍵を持たず、短命の証明書で署名
- OIDC（OpenID Connect）による identity 検証
- Rekor という公開透明性ログに署名を記録
### 8.2 gitsign
`gitsign` は、Sigstore を使った Git コミット署名ツール[^13]：
- 短命の証明書（10 分有効）で署名
- OIDC（Google、GitHub、Microsoft 等の ID プロバイダ）で identity 検証
- 鍵管理の負担を排除
特に CI/CD 環境での自動署名に向く設計である。
### 8.3 信頼モデル
gitsign の信頼は以下に依存する：
- OIDC プロバイダ（Google、GitHub 等）
- Fulcio（証明書発行 CA）
- Rekor（透明性ログ）
GPG の Web of Trust や、鍵をローカル保管する SSH 署名とは、根本的に異なる信頼モデルを持つ。
---
## 9. 組織での署名強制：実践の二つの方向
### 9.1 GitHub の Branch Protection Rules
GitHub は、リポジトリの branch protection rules で「**Require signed commits**」を設定できる[^14]：
- 署名検証されないコミットは push が拒否される
- 検証された署名付きコミットのみが merge 可能
- 大企業・規制対応の文脈で採用される
### 9.2 強制を採用する組織
技術ブログでは、署名強制を推奨する論調がある[^15][^16]：
- なりすましコミットの防止
- 監査ログとしての価値
- ソフトウェアサプライチェーン攻撃への防御
### 9.3 強制を廃止した事例：OpenBao
OpenBao（HashiCorp Vault のフォーク）の Issue #399 は、署名強制を廃止する決定を行い、その理由を以下のように述べている[^17]：
- 新規貢献者の参入障壁
- 通常の貢献者の作業負荷増加
- 技術的知識のない貢献者の排除（多様性の損失）
- GitHub から SSH 鍵を削除すると過去の Verified コミットが Unverified 表示になる時間的有効性の問題
- rebase 時の署名喪失
- Web of Trust 相当の検証経路の不在
ただし、最終的な合意は「一般貢献者への署名強制は廃止しつつ、**メンテナのコミットには署名を必須とするワークフロー（Issue #447）を導入する**」という折衷案であった。つまり、署名強制を完全に放棄したのではなく、**強制対象を貢献者全体からメンテナに限定**する形で再構成された。
### 9.4 文脈依存性
複数の情報源が、署名強制の判断は文脈に依存することを示唆している：
- **大企業・規制対応**：強制が合理的
- **OSS プロジェクト**：強制は貢献者を排除しうる、Vigilant Mode 等の検出機能で十分な場合も
- **個人プロジェクト**：強制不要
---
## 10. rebase と署名の構造的緊張
### 10.1 「rebase すると署名が無効になる」現象
業界で広く認識された問題[^18][^19]：
- rebase はコミットを書き換える（メタデータ・親コミット・タイムスタンプが変わる）
- 結果として SHA ハッシュが変わる
- 元の署名は新しいコミット（新しい SHA）には付かない
- 「Verified」バッジが消える
これは「バグ」ではなく、暗号学的に自然な挙動である。署名は特定の SHA に対する暗号学的コミットメントだから、SHA が変われば署名は新コミットには付かない。
### 10.2 GitLab における未解決 Issue
GitLab Issue #33431[^20]：
> Gitlab allows a reviewer to rebase the branch of a merge request from the UI. The automatic rebase can (obviously) not re-sign GPG signed commits when doing so, but does the rebase anyway, leading to signature loss.
（参考訳：GitLab では、レビュアーがマージリクエストのブランチを UI から rebase できる。自動 rebase は、当然のことながら、GPG 署名されたコミットを再署名することはできないが、それでも rebase は実行され、結果として署名が失われる。）
GitLab の UI から rebase すると、署名が失われる。
### 10.3 GitHub の Merge 戦略との関係
GitHub Docs[^1]：
> When using the Rebase and Merge option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification.
（参考訳：プルリクエストで「Rebase and Merge」オプションを使用する際、head ブランチのコミットがコミット署名検証なしに base ブランチに追加されることに注意することが重要である。）
GitHub の「Rebase and Merge」を使うと、署名検証なしでコミットが追加される。
### 10.4 推奨される対応（技術ブログより）
業界で議論される対応[^18][^19]：
- Merge commit を使う（rebase を避ける）
- Squash and merge を使う（最終 merge commit は GitHub web-flow 鍵が署名）
- Linear history 強制を避ける
- rebase 後に再署名するスクリプト
---
## 11. GitHub Desktop の制約
複数の情報源が指摘する制約[^21]：
GitHub Desktop は、独自の署名 UI を持たない。ただし、システムの Git クライアントが `commit.gpgsign=true` 等の設定で署名するように構成されていれば、GitHub Desktop からのコミット時にも内部的に Git が呼び出され、自動的に署名される。
つまり：
- GitHub Desktop **だけ**で署名設定を完結することはできない
- 事前に Git CLI 側で署名設定を行えば、GitHub Desktop からのコミットも署名される
- ハードウェアトークン経由の署名（PIN 入力等）は、GitHub Desktop の操作中にダイアログとして現れる
---
## 12. GitHub の「Vigilant Mode」
GitHub には Vigilant Mode という機能がある[^22]：
- 全コミット・タグに署名検証状態を表示
- Author 名と署名の identity を照合
- 「Verified」「Partially verified」「Unverified」の三段階で表示
- なりすましコミット（他人の名前で push されたもの）の視覚的識別を支援
§2.1 の研究によれば、Vigilant Mode の導入は短期的には署名コミット数の増加に寄与したが、その後の長期的な増加は限定的だった。
---
## 13. 業界の議論で十分に語られていない論点
各情報源を整理して気づいたが、以下の論点は技術ブログ等で十分に議論されていない：
### 13.1 Key Separation Principle と SSH 署名の関係
業界の技術ブログは、SSH 認証鍵を署名にも流用する利点を強調することが多い。しかし、これは §5 で述べた Key Separation Principle と緊張関係にある。この緊張を踏み込んで議論する記事は少ない。
### 13.2 リポジトリの自己完結性
PGP の独立検証可能性と、SSH の `allowed_signers` 依存の構造的差異。「GitHub がダウンしている時の検証可能性」という観点は、技術ブログでは語られにくい。
### 13.3 `allowed_signers` 設定者の責任
`allowed_signers` の正確性が、検証者の責任に分散される構造。誤った登録による誤検証のリスクは、業界の議論では十分に整理されていない。
### 13.4 PAT/OAuth トークン保護との統合的観点
コミット署名と並行して論じられるべき「書き込みアクセス権の保護」（PAT、OAuth トークン）の問題。署名と認証経路の保護は、本来一体として論じられるべきだが、業界の議論では分離されがちである。
### 13.5 ハードウェアトークン運用上の不便
OpenPGP カードが時々認識しなくなる等の、運用上の細かい問題。「対応策が確立しているが一手間」というレベルの現実的認識は、業界の議論ではほぼ語られない。
---
## 14. 考察：コミット署名における「権威」の構造
本節は事実報告ではなく、**構造的な考察**である。本レポート全体の事実情報を踏まえて、コミット署名運用に内在する「権威」の構造を整理する。考察として位置付け、今後のさらなる調査の出発点とする。
### 14.1 公開鍵署名検証の二段階構造
公開鍵暗号における署名検証は、暗号学的に二段階の問題に分解できる：
| 段階 | 検証内容 | 検証方法 |
|---|---|---|
| 暗号学的真正性 | この署名は、この公開鍵で作られたか | 数学的に検証可能 |
| identity の真正性 | この公開鍵は、誰のものか | 数学だけでは決まらない |
第二段階は、必ず**何らかの「権威」**（identity を保証する出所）を必要とする。誰かが「**この公開鍵はある特定の人物のものだ**」と最初に表明しなければ、検証者は鍵を identity に結びつけられない。
これは公開鍵暗号の本質的性質であり、特定の技術プロトコル（PGP、SSH、S/MIME、Sigstore 等）に依存しない。
### 14.2 「権威」の多様な形
本レポートで整理した各事例には、それぞれ異なる形の「権威」が存在する：
#### Linux カーネルの場合：Linus Torvalds の鍵束
§3 で整理した通り、Linux カーネルコミュニティは独自の PGP 鍵リポジトリ（korg-pgpkeys）を運営している：
- Linus Torvalds の鍵を起点とする trust path（リポジトリ内の既存鍵から署名を受け、Linus まで trust path を辿れること）が、鍵を受け入れる条件
- 2011 年の Kernel Summit でのキーサイニングセッションで信頼の輪をブートストラップ
- Konstantin Ryabitsev が管理
機能的には、**Linus Torvalds の鍵束が「事実上の認証局」として機能している**と言える。プロトコル上は分散的な Web of Trust だが、運用としては Linus の鍵を最終的な権威としている。
#### 一般の GitHub ユーザーの場合：GitHub アカウント基盤
§2.2 で確認した通り、GitHub 上の Verified 表示の大半は、GitHub Web UI 経由の自動署名による。これは「**GitHub アカウントで認証された操作**」が、Verified 表示の根拠となっている構造である：
- GitHub アカウントには MFA、メール確認、サインインログ等の認証基盤が紐付く
- push 権限を持つには、GitHub アカウントへの認証が必要
- GitHub Web UI 経由のコミットは、GitHub の web-flow 鍵で自動署名される
機能的には、**GitHub のアカウント認証基盤が「事実上の認証局」として機能している**と言える。
#### 商用 PKI 環境の場合：公的 CA
S/MIME 署名や、企業内で運用される X.509 ベースの署名では、**公的または組織内の認証局（CA）が明示的に「権威」**として位置付けられる。これは PKI（Public Key Infrastructure）の標準的な構造である。
#### Sigstore の場合：OIDC プロバイダ + Fulcio + Rekor
§8 で整理した Sigstore は、以下の組み合わせで権威を構築する：
- OIDC プロバイダ（Google、GitHub、Microsoft 等）：identity の検証
- Fulcio：短命証明書の発行
- Rekor：透明性ログ
機能的には、**OIDC プロバイダが「事実上の認証局」として機能している**（証明書発行は Fulcio が行うが、identity の源泉は OIDC プロバイダ）。
### 14.3 構造的な同型性
これらの事例を並べると、**技術プロトコルの違いを超えて、機能的に同型な構造**が見える：
| 事例 | 「権威」に相当するもの | 信頼の根拠 |
|---|---|---|
| Linux カーネル | Linus Torvalds の鍵束（korg-pgpkeys） | 2011 年キーサイニングセッション、Linus まで trust path を辿れる鍵のみを受け入れる運用 |
| 一般 GitHub ユーザー | GitHub アカウント基盤 | MFA、メール確認、サインインログ等 |
| 商用 PKI 環境 | 公的 CA（X.509） | CA の運用責任、ルート証明書の信頼 |
| Sigstore | OIDC プロバイダ + Fulcio + Rekor | 短命証明書、透明性ログ |
技術プロトコル（PGP、SSH、S/MIME、Sigstore）は異なるが、**「権威への信頼」の存在は共通**である。
業界の議論は、しばしば「PGP vs SSH vs S/MIME」という技術的な対立軸で語られる。しかし、機能的観点から見れば、いずれの方式も「**何らかの権威を必要とする**」点で同じである。「PGP は分散的だから優れている」という議論も、実態として Linux カーネルで Linus の鍵束という事実上の権威が機能していることを踏まえると、表層的である。
### 14.4 §2 の学術研究データの再解釈
この構造的観点で §2 の学術研究データを見直すと、別の解釈が可能になる：
- 学術研究：非 UI コミットを行ったユーザーのうち、ローカル鍵で能動的に署名した経験のあるユーザーは 5.94% のみ（§2.2）
- 一方、GitHub 上の全体署名率は 24.05%、署名済みコミットの 82.69% は GitHub Web UI 経由の自動署名（同）
この乖離は、「**多くの開発者が GitHub アカウント基盤を事実上の認証局として信頼している**」と解釈できる。能動的な署名をしない開発者の多くは、「GitHub のアカウント認証が信頼の根拠として十分」と暗黙に判断している、と説明できる。
これは「**怠慢**」や「**認識不足**」ではなく、「**異なる権威モデルへの依拠**」として理解しうる。
### 14.5 「権威」の規模・性質との対応
異なる権威の形は、コミュニティの規模・性質と対応関係を持つ可能性がある：
- **Linux カーネル開発（相対的に閉じた、専門的なコミュニティ）**：Linus を中心とする個人的信頼ネットワークが機能する
- **一般の GitHub ユーザー（広範で多様なコミュニティ）**：個人的信頼ネットワークは規模的に成立せず、プラットフォーム認証基盤が機能する
- **商用 PKI 環境（規制・契約関係のあるコミュニティ）**：CA という明示的な権威構造が機能する
- **CI/CD 等の自動化環境（人間の関与が排除される）**：短命証明書と透明性ログという仕組みが機能する
つまり、「**コミュニティの規模・性質に応じて、機能する権威の形が異なる**」という構造である。
### 14.6 自前 Git 運用における署名励行との関係
業界には「自前 Git ホスティング（GitLab セルフホスト、Gitea 等）では、署名が励行される傾向がある」という観察的言及がある。
本節の構造分析を踏まえると、これは以下のように解釈できる：
- 自前 Git ホスティングは、GitHub のような巨大な認証基盤を持たない
- そのため、「**プラットフォームを事実上の認証局として信頼する**」という暗黙の依拠が成立しにくい
- 結果として、暗号学的署名による明示的な真正性担保が必要となる
つまり、署名が励行されるかどうかは、「**プラットフォームの権威がどれだけ信頼に足るか**」と、「**暗号学的署名による明示的な担保がどれだけ必要か**」のバランスで決まる、と解釈できる。
### 14.7 考察の限界
本節の構造分析には、以下の限界がある：
- 「権威」「事実上の認証局」という概念整理は、本レポートの分析枠組みに基づくものであり、業界で広く合意された用語ではない
- 各事例の「権威」の機能的等価性は、構造的観察であり、定量的に検証されたものではない
- 開発者が「GitHub を事実上の認証局として信頼している」という心理的解釈は、推測の域を出ない
- 他の説明枠組み（学習コスト、設定の煩雑さ、認識不足等）も並列で考えうる
本レポートでは、この構造分析を「事実情報の整理から導かれる一つの考察」として位置付け、今後のさらなる調査の出発点とする。
### 14.8 今後の調査課題
この構造分析を踏まえると、以下のような調査課題が浮かぶ：
- 各「権威」の形が、どのような条件下で機能し、どのような条件下で破綻するか
- コミュニティの規模・性質と、機能する権威の形の対応関係の定量的検証
- 「自前 Git 運用での署名励行」の定量的調査
- プラットフォーム認証基盤（GitHub アカウント）が侵害された場合の影響範囲分析
- 異なる権威モデルの併用（例：プラットフォーム認証 + ローカル PGP 署名）の効果
これらは本レポートの範囲を超えるため、別途の調査として位置付ける。
---
## 15. 本調査の限界
### 15.1 情報源の偏り
- 英語圏の情報源が中心
- 個人ブログ・技術ブログが多く、学術的・規格的な議論は限定的
- 商用ベンダー（Yubico、Keeper 等）の記事は、自社製品推奨の傾向を持つ
### 15.2 学術研究のサンプル
§2 で参照した学術研究は、それぞれサンプリング手法を持つ：
- 研究 1：60 リポジトリの「人気順」サンプル
- 研究 2：71,694 開発者の階層化サンプル
これらは特定の母集団を対象としており、Git ユーザー全体への一般化には注意が必要である。
### 15.3 ベストプラクティスの相対性
業界として完全に統一された「ベストプラクティス」は存在しない。本レポートで整理した内容は、複数の見解と実態の**現時点での集約**であり、将来別の見解が主流になる可能性がある。
### 15.4 本レポートの有効期限
- Web 上の情報は時間と共に古くなる
- 各ツール（GnuPG、OpenSSH、GitHub 等）のバージョンアップで状況が変化する
- 2026 年 6 月時点の調査として位置付ける
---
## 脚注
[^1]: GitHub Docs "About commit signature verification" https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification (2026-06-04 参照)
[^2]: Sharma, A., Karmakar, S., Kancherla, G. P., Bichhawat, A. "On the Prevalence and Usage of Commit Signing on GitHub: A Longitudinal and Cross-Domain Study" arXiv:2504.19215 (2025-04) https://arxiv.org/abs/2504.19215 (2026-06-04 参照)
[^3]: Shittu, A. S., et al. "Analysis of Commit Signing on Github" arXiv:2604.14014 (2026-04) https://arxiv.org/abs/2604.14014 (2026-06-04 参照)
[^4]: OpenSSH 8.1 リリースノート（2019-10-09）。実験的な軽量署名・検証機能（`ssh-keygen -Y sign` / `ssh-keygen -Y verify` の基盤）が New Features として追加 https://www.openssh.com/txt/release-8.1 (2026-06-04 参照)
[^5]: Git 2.34.0 リリースノート（2021-11-15）。SSH 鍵によるコミット・タグ署名のサポート追加 https://github.com/git/git/blob/master/Documentation/RelNotes/2.34.0.txt (2026-06-04 参照)
[^6]: Manuel Laggner "Signing Git Commits with GPG and SSH: A Complete Guide" (2025-01-14) https://www.laggner.info/posts/sign-git-commits-with-gpg-ssh/ (2026-06-04 参照)
[^7]: Ken Muse "Comparing GitHub Commit Signing Options" (2022-10-07) https://www.kenmuse.com/blog/comparing-github-commit-signing-options/ (2026-06-04 参照)
[^8]: Tim Bastin "Security enhancement in the software development process: A detailed guide to integrating a YubiKey with Git, commit signing and GitLab" Medium (2023-07-04) https://medium.com/@timbastin/security-enhancement-in-the-software-development-process-a-detailed-guide-to-integrating-a-yubikey-851ee4b5b460 (2026-06-04 参照)
[^9]: Ryan Spletzer "A No-Nonsense Guide to GPG Commit Signing with a YubiKey" (2026-04-11) https://www.spletzer.com/2026/04/a-no-nonsense-guide-to-gpg-commit-signing-with-a-yubikey/ (2026-06-04 参照)
[^10]: OpenSSH 8.2 リリースノート（2020-02-14）。FIDO U2F セキュリティキーのサポート追加 https://www.openssh.com/releasenotes.html (2026-06-04 参照)
[^11]: Yubico Developers "Git Commit Signing with YubiKey and SSH/FIDO2" https://developers.yubico.com/SSH/Securing_git_with_SSH_and_FIDO2.html (2026-06-04 参照)
[^12]: Sigstore プロジェクト公式サイト https://www.sigstore.dev/ (2026-06-04 参照)
[^13]: gitsign プロジェクト https://github.com/sigstore/gitsign (2026-06-04 参照)
[^14]: GitHub Docs "Managing a branch protection rule" https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule (2026-06-04 参照)
[^15]: Anuj Sharma "How to Set Up SSH & GPG Signed Commits on GitHub to Block Force-Push Attacks" DEV Community https://dev.to/ankushppie/how-to-set-up-ssh-gpg-signed-commits-on-github-to-block-force-push-attacks-5g56 (2026-06-04 参照)
[^16]: How-To Geek "How to Secure Your Git Repository with Signed Commits and Tags" (2023-07-05) https://www.howtogeek.com/devops/how-to-secure-your-git-repository-with-signed-commits-and-tags/ (2026-06-04 参照)
[^17]: OpenBao Issue #399 "Discontinue Enforcing Signed Commits via Branch Protection Rules" (2024-07-11) https://github.com/openbao/openbao/issues/399 (2026-06-04 参照) ─ 関連 RFC：https://openbao.org/docs/rfcs/signed-commits/ (2026-06-04 参照)
[^18]: codegenes.net "Verified Signatures Gone After Rebase and Merge? How to Preserve Git Verified Commits When Merging Develop to Master" https://www.codegenes.net/blog/verified-signatures-are-gone-after-i-pressed-rebase-and-merge/ (2026-06-04 参照)
[^19]: DEV Community "Enhancing Git Security and Workflow: A Comprehensive Guide to Signed Commits and a Linear History" (2025-09-01) https://dev.to/it-wibrc/enhancing-git-security-and-workflow-a-comprehensive-guide-to-signed-commits-and-a-linear-history-4ih0 (2026-06-04 参照)
[^20]: GitLab Issue #33431 "Prevent rebasing from UI for branches containing GPG signed commits" https://gitlab.com/gitlab-org/gitlab/-/issues/33431 (2026-06-04 参照)
[^21]: GitHub Enterprise Server Docs (複数バージョン) "Signing commits" の節。GitHub Desktop の制約に関する記述。なお、独立した実証研究としては arXiv:2504.19215 §5.2.1 が「GitHub Desktop does not support commit signing and solely depends on Git configurations for signing commits」と報告している
[^22]: Ross Butler "Protect Yourself Against Commits Forged In Your Name Using GitHub's New Vigilant Mode" Medium (2021-08-11) https://medium.com/@rwbutler/protect-yourself-against-commits-forged-in-your-name-using-githubs-new-vigilant-mode-84ed00a71f94 (2026-06-04 参照) ─ なお Vigilant Mode の一次情報としては、GitHub Docs "Displaying verification statuses for all of your commits" および GitHub Changelog "Flag unsigned commits with vigilant mode"（2021-04-28）を参照
[^23]: Developer Certificate of Origin Version 1.1 https://developercertificate.org/ (2026-06-04 参照)
[^24]: Greg Kroah-Hartman, Andrew Morton, Linus Torvalds "We can not allow anonymous contributions to the kernel" (Linux kernel commit) ─ Documentation/SubmittingPatches への匿名禁止の追記
[^25]: Linux Kernel Documentation "Kernel Maintainer PGP guide" https://docs.kernel.org/process/maintainer-pgp-guide.html (2026-06-04 参照)
[^26]: kernel.org PGP keyring documentation https://korg.docs.kernel.org/pgpkeys.html (2026-06-04 参照)
[^27]: Linus Torvalds による [GIT PULL] Crypto Update for 5.18 への返信 (2022-03-21) https://lkml.iu.edu/2203.2/06024.html (2026-06-04 参照)
[^28]: Jonathan Corbet "Maintaining the kernel's web of trust" LWN.net (2019-09-04) https://lwn.net/Articles/798230/ (2026-06-04 参照)
[^29]: Linus Torvalds による [GIT PULL] integrity subsystem updates for v5.17 への返信 (2022-01-11) https://lkml.iu.edu/hypermail/linux/kernel/2201.1/03438.html (2026-06-04 参照)