security: add cryptographic signature verification for self-update artifacts

[t0k0sh1]

security: add cryptographic signature verification for self-update artifacts

Summary

self-update は SHA-256 checksum で artifact の整合性を検証しているが、checksums.txt 自体の真正性を検証する仕組みがない。攻撃者が GitHub リリースアセットを改ざんできる状況では、archive と checksums.txt の両方を差し替えることで checksum 検証をすり抜けられる。

Current State

• SHA-256 checksum 検証は実装済み（checksums.txt と archive のハッシュ照合）
• tar entry の安全性検証も実装済み（symlink, absolute path, path traversal の拒否）
• HTTPS 経由のダウンロードにより通信経路上の改ざんはある程度防止されている
• しかし、checksums.txt 自体が改ざんされた場合に検出する手段がない

Impact

• リリースアセットへの書き込み権限を持つ攻撃者が、archive と checksums.txt を同時に差し替え可能
• 改ざんされたバイナリと stdlib がユーザー環境にインストールされるリスク
• self-update は supply-chain 上の重要経路であり、真正性の担保が望ましい

Proposed Approach

案1: GPG 署名

• リリース時に checksums.txt.sig を GPG 秘密鍵で生成し、release asset として配布
• self-update 時に公開鍵で checksums.txt.sig を検証してから checksum 照合を実施
• 公開鍵はバイナリに埋め込むか、well-known な場所から取得

案2: minisign / signify

• GPG より軽量な署名ツール（minisign 等）を使用
• Ed25519 ベースで鍵管理がシンプル
• Go, Zig 等のツールチェインで採用実績あり

案3: cosign (Sigstore)

• keyless signing で鍵管理の負担を最小化
• GitHub Actions の OIDC トークンと連携可能
• ただし cosign コマンドの依存が増える

Considerations

• 鍵の生成・保管・ローテーション方針の策定が必要
• CI/CD ワークフロー（release.yml, dev-release.yml）への署名ステップ追加
• self-update クライアント側での検証ロジック追加
• 検証に必要な外部コマンド（gpg, minisign 等）の依存管理
• 署名検証が利用できない環境でのフォールバック方針

Related

• security: verify self-update artifacts before install #110 — self-update artifact 検証の親 issue
• src/self_update.cpp — 現在の checksum 検証実装