Copilot Cloud沙箱commit用用户git身份且无GPG签名，未经verified的commit混进历史谁来兜？

一、导语：一条“看起来是你写的”提交

设想这样一个场景：你在 GitHub 上启用 Copilot 的云端编码代理，让它在一个隔离沙箱里修复一个 issue。几分钟后，一条 PR 出现在你的仓库里，提交信息工整，作者栏赫然写着你的名字和邮箱，但提交旁边没有那个绿色的 “Verified” 徽章，而是一个灰色的 “Unverified”。点开详情，GitHub 提示“该提交的签名无法验证，或提交者未使用签名密钥”。这条提交已经进入分支历史，甚至可能被合并进主干。问题随之而来：如果这条提交引入了恶意代码或敏感信息泄露，责任链条上究竟该由谁承担？

这不是一个孤立的 UI 细节，而是“自动化代理以人类身份写入版本历史”这一范式带来的结构性张力。Git 从设计之初就把“身份”与“认证”分开处理：author/committer 字段只是自由文本，任何人都可以写成任何值；真正的来源证明依赖附加的 GPG 或 SSH 签名。当云端沙箱复用用户身份却不签名时，历史记录便进入一种“作者可信、来源不可证”的中间态。本文要回答的核心问题是：这种中间态为何产生、风险边界在哪里、工程上如何兜底。

本文评述：把“谁兜”当作一个纯合规问题是不够的。它首先是一个密码学协议问题——签名链在哪一环断裂；其次才是一个流程问题——断裂之后用什么机制补位。厘清这个次序，后面的方案才不会沦为堆砌策略。

二、背景与问题定义：Git 身份、签名与 verified 的真实含义

2.1 Git 提交对象的身份字段是“声明”而非“证明”

在 Git 的对象模型中，一个 commit 对象包含 tree 指针、父提交、author、committer 以及提交信息。author 与 committer 各自是“名字 <邮箱> 时间戳 时区”的文本串。Git 本身不校验这个文本串与任何密钥的绑定关系，也不要求写入者拥有该邮箱。换言之，身份字段是声明性的（declarative），不是证明性的（proving）。这一点在 Git 官方文档与 Pro Git 一书中均有明确表述：签名是独立于提交内容之外的可选附加物。

GitHub 的 “Verified” 徽章正是对这一附加物的展示：平台用提交者上传到账户的公钥去验证 commit 对象上的签名，验证通过才显示绿色徽章。因此，“Unverified” 并不等于“伪造”，它只表示“平台无法把这条提交与某个已知密钥关联起来”。这个区分是全文论证的基石——混淆二者会导致治理方向跑偏。

2.2 签名机制：GPG 与 SSH 签名的差异

Git 支持多种签名后端。传统方式是 GPG（OpenPGP）签名，通过 git commit -S 触发，签名被写入 commit 对象的 gpgsig 头。较新的方式是 SSH 签名（Git 2.34 起支持），利用已有的 SSH 密钥完成签名，配置成本更低。两者在密码学上都提供“持有私钥者对内容背书”的证明，但信任模型不同：GPG 依赖 Web of Trust 或平台托管公钥，SSH 签名则依赖平台把公钥与账户绑定。

本文评述：从工程角度看，SSH 签名降低了“让自动化流程签名”的门槛，但并没有改变根本矛盾——私钥必须进入沙箱，而沙箱是攻击面。因此，问题的关键不是“选哪种签名”，而是“私钥是否应该进入沙箱”。这个判断直接决定了后文治理路线的取舍。

2.3 问题定义：三个可分离的子问题

把现象拆开，可以得到三个层次不同、解法也不同的子问题。第一是身份委托问题：沙箱凭什么以用户名义提交？第二是签名链断裂问题：为什么提交没有附带可验证的签名？第三是信任边界问题：未验证提交进入历史后，下游如何识别与处置？三者分别对应授权、密码学与审计，混为一谈会让方案失焦。

三、机制拆解：沙箱为何“有身份、无签名”

3.1 身份委托的实现路径

云端编码代理通常通过 OAuth 或 GitHub App 获得代表用户操作的令牌。沙箱在克隆仓库后，会配置 user.name 与 user.email，使其与用户账户一致，然后执行提交与推送。这一设计的目标是让提交在归属上清晰可追溯——PR 显示为“由你发起”，便于评审与责任归属。从产品体验看，这无可厚非；从安全模型看，它把“身份声明”与“操作主体”做了松耦合。

关键在于，令牌授权的是“代表用户调用 API 的权限”，而不是“代表用户生成密码学证明的权限”。前者是 OAuth 作用域层面的授权，后者需要私钥。两者之间没有自动传导关系。因此，沙箱能推送、能创建 PR，却天然无法产生 verified 签名——除非额外把私钥交给它。

3.2 签名链的断裂点

一条提交从生成到显示 verified，需要满足：提交对象带有 gpgsig 或 SSH 签名头；签名所用公钥已绑定到提交者账户；签名内容与提交对象哈希一致。沙箱场景下，第一环就缺失。即便沙箱配置了签名，若私钥是平台共享密钥而非用户密钥，验证结果会显示为“由某机器人验证”，而非用户本人。这引出一个容易被忽视的细节：verified 的主体是密钥持有者，不是身份字段的填写者。

# 查看提交是否带签名（无输出即无签名）
git cat-file -p <commit-sha> | grep -E '^(gpgsig|-----BEGIN)'

# 本地验证签名
git verify-commit <commit-sha>

# 查看签名者与密钥指纹
git log --show-signature -1 <commit-sha>

本文评述：很多团队把“提交显示 Unverified”当成平台 bug，实际上这是协议如实反映了“没有可验证证明”的事实。把断裂点定位在“私钥未参与”而非“平台校验失败”，才能找到正确的修复位置。

3.3 为什么平台不默认代签

从平台视角看，代用户签名意味着平台要持有或代理用户的私钥，这会显著扩大信任面：一旦平台侧密钥泄露，攻击者可伪造任意用户的提交。相比之下，“以用户身份提交但不签名”在责任划分上更保守——平台只承担“代理执行”的角色，不承担“密码学背书”的角色。这是一种有意的边界设计，而非疏漏。理解这一点，有助于判断哪些诉求可以推动平台改变，哪些必须由使用方自行兜底。

四、关键数据与案例：Unverified 提交的规模与风险面

4.1 可观测的规模信号

目前没有公开的、按“自动化代理提交”细分的 Unverified 比例统计，任何精确数字都应谨慎对待。可观测的替代信号包括：GitHub 官方文档对签名验证规则的说明、Git 项目对 SSH 签名的引入、以及开源社区关于“机器人提交是否应签名”的讨论。这些信号共同指向一个趋势——自动化提交占比上升，而签名覆盖率并未同步上升。本文在此不引用未经核实的比例数字，而是把“规模”作为一个需要团队自行度量的量。

团队可以用如下命令在本地对仓库历史做一次签名覆盖率抽样，作为基线：

# 统计最近 500 条提交中带签名的比例（近似）
total=0; signed=0
for c in $(git rev-list -n 500 HEAD); do
  total=$((total+1))
  if git cat-file -p "$c" | grep -q '^gpgsig'; then signed=$((signed+1)); fi
done
echo "signed=$signed total=$total"

需要说明的是，上述脚本只检测 GPG 签名头，SSH 签名在对象中的表示不同，实际统计需结合 git log --show-signature 的输出解析。这属于模拟/整合数据的采集方法，具体数值因仓库而异，本文不给出虚构比例。

4.2 风险面的三个维度

第一是供应链完整性：未签名提交无法证明“内容在离开沙箱后未被篡改”，若中间环节被攻破，历史记录无法自证。第二是责任归属：提交显示为用户，但用户可能从未逐行审阅代理生成的内容，出事时“作者”与“审阅者”角色错位。第三是合规审计：部分行业规范要求代码变更具备可验证的来源证明，Unverified 提交在审计时会被标记为待解释项。

笔者认为：把风险简单归为“签名缺失”会低估问题。真正的风险是“身份声明与证明能力不匹配”造成的信任错觉——评审者看到熟悉的名字，会下意识降低警惕。这种心理层面的松弛，比密码学缺口更难治理。

五、对比与局限：三种治理路线的取舍

5.1 路线一：把私钥交给沙箱

最直接的做法是在沙箱内注入签名私钥，让提交自带签名。优点是链路最短、验证结果最“干净”。局限也很明显：私钥进入了一个由第三方编排、可能运行不可信代码的环境，攻击面显著扩大；密钥轮换、吊销、审计都变得复杂。本文评述：除非沙箱的隔离强度与密钥托管达到同等水平，否则这条路线的风险收益比不佳。

5.2 路线二：平台侧代签

由平台用托管密钥代签，提交显示为“由平台验证”。优点是用户无需管理密钥；局限是 verified 的主体变成平台而非用户，责任语义发生变化，且平台成为单点信任。本文评述：这条路线在“可证”上有效，在“归属”上弱化，适合对来源证明要求高于个人归属的场景。

5.3 路线三：合并前签名网关

在合并入口设置网关，对进入主干的提交统一做签名或重写。优点是私钥不必进入沙箱，签名发生在受控环境；局限是历史中的旧提交无法追溯补签，且网关本身成为关键路径。下表对比三种路线：

六、操作路径：签名网关、策略校验与审计回溯

6.1 第一步：建立签名基线

先度量再治理。用 4.1 的脚本对主干历史做抽样，得到当前签名覆盖率；同时统计“作者为人类但无签名”的提交占比，作为需要兜底的目标集合。把这两个数字写入团队的可观测看板，作为后续改进的对照。

6.2 第二步：在合并入口部署签名网关

网关的职责不是“替所有提交签名”，而是“确保进入受保护分支的提交具备可验证来源”。一种可行实现是：在 CI 中增加一个校验 job，对 PR 的每个提交执行 git verify-commit，未通过则阻断合并；对于代理生成的提交，要求其通过受控的 rebase/重签流程后再进入主干。这样私钥只存在于受控环境，沙箱无需持有。

# CI 中的签名校验片段（示意）
set -e
for c in $(git rev-list origin/main..HEAD); do
  if ! git verify-commit "$c" 2>/dev/null; then
    echo "unsigned commit: $c"
    exit 1
  fi
done

本文评述：网关方案的价值在于把“签名能力”与“执行环境”解耦。沙箱负责生成内容，网关负责背书来源，两者职责清晰。代价是合并流程多了一步，需要用自动化把摩擦降到可接受水平。

6.3 第三步：策略校验与分支保护

在仓库设置中启用“Require signed commits”分支保护，可强制新提交必须签名。对历史中的 Unverified 提交，无法通过设置追溯修复，只能通过审计标注与渐进式重写处理。建议把“代理提交必须经网关重签”写入贡献规范，并在 PR 模板中提示评审者关注提交来源。

6.4 第四步：审计回溯与责任留痕

对每一条代理生成的提交，保留“沙箱会话 ID—代理版本—用户授权记录”的映射，写入独立的审计日志。这样即便提交本身未签名，也能在事后通过日志还原“谁授权、哪个代理、在何时生成”。这是一种补偿性控制，不能替代密码学证明，但能在事故调查中提供关键证据链。

延伸阅读与工具参考（新窗口打开）：Pro Git：签署工作、GitHub 提交签名验证文档、GitHub Actions 文档。

七、结论与展望：把“谁兜”变成“可证”

回到标题的问题：未经 verified 的 commit 混进历史，谁来兜？本文的答案是——不能依赖单一主体“兜底”，而要把问题转化为“如何让来源可证”。身份委托解决的是“谁发起”，签名解决的是“谁背书”，审计解决的是“事后能否还原”。三者缺一不可，且不能互相替代。沙箱以用户身份提交却不签名，本质上是把“发起”与“背书”解耦，工程上必须用网关和策略把背书补回来。

展望未来，两个方向值得关注。其一是平台层面的“代理签名”标准化：如果出现一种机制，能让代理在受限条件下获得短期、可审计的签名能力，而不暴露长期私钥，签名链断裂问题会大幅缓解。其二是供应链安全领域对“自动化提交”的专门规范：把代理生成的提交作为一类独立来源对待，要求其携带可验证的代理标识，而非简单复用人类身份。本文评述：这两条路径都需要平台与使用方共同推动，短期内最务实的仍是合并网关加审计留痕的组合。

最后需要强调边界条件：本文讨论的方案针对“受保护分支的合并入口”，对个人分支、临时实验分支并不强制；签名覆盖率的目标值应结合团队规模与合规要求设定，不存在普适阈值。任何治理方案都应先度量、再设计、后验证，避免为了“看起来安全”而引入新的流程瓶颈。