签名是真的，分支却不对：GitHub CLI 制品证明的大小写边界

一、背景与时间线

官方确认 gh attestation verify 对 --source-ref 使用不区分大小写的比较，而 Git ref 区分大小写。攻击前提是对已信任仓库拥有写权限，能够创建大小写不同的分支。证明签名与证书本身没有损坏；--source-digest 不受该问题影响，可用于固定批准的提交。公告未列出 CVE，本文只使用 GHSA 标识。

以上事实依据项目安全公告。这里的披露或数据库收录日期不是攻击发生时间。本次核验的一手来源没有确认在野利用，本文不据此断言不存在攻击。

二、影响范围与版本边界

项目	核验结果
公告标识	GHSA-4mq3-hpgx-9cx8
项目公告日期	2026-09-30
受影响版本	>=2.68.0 且 <=2.101.0
修复版本	2.102.0
事件性质	漏洞披露或近期数据库收录，非已确认攻击事件

版本信息应结合实际运行环境判断。依赖清单命中仅是第一步，还需要确认调用路径、配置和不可信输入能否到达相应逻辑。发行商回补补丁的情况，应核对其安全公告和构建证据，不能只按上游版本字符串做最终判断。

三、技术原理与工程分析

设发布政策允许 refs/heads/Release，实际构建来自 refs/heads/release。将二者统一转为小写后，原本不同的身份进入同一个等价类。问题不是字符串不够规范，而是规范化规则不符合对象本身的身份规则。

工程分析：门禁至少存在四个不同问题------字节是否对应制品、证明是谁签发、构建来自哪个源码对象、该源码对象是否被允许发布。任何一层通过，都不能代替下一层。尤其不能将仓库可信扩大为仓库中所有分支可信。

建议将证明中的仓库、ref、commit 和构建工作流保留为独立字段。ref 比较遵循精确语义，commit 用于固定一次批准对象，策略变更单独审计。这样回溯时可以回答批准的是哪个提交，而不只是哪个分支名称。

四、防御性安全示例

以下Python 3示例只演示安全不变量，不连接网络、不执行外部程序、不生成真实利用载荷，也不是厂商补丁的逐行复现。运行后应输出检查通过。

python 复制代码

expected = 'refs/heads/Release'
actual = 'refs/heads/release'
assert expected.casefold() == actual.casefold()
assert expected != actual

def approve(ref, digest, policy):
    return ref == policy['ref'] and digest == policy['digest']

policy = {'ref': expected, 'digest': 'demo-commit-A'}
assert approve(expected, 'demo-commit-A', policy)
assert not approve(actual, 'demo-commit-A', policy)
assert not approve(expected, 'demo-commit-B', policy)
print('policy checks passed')

模型测试通过只证明这些固定输入满足预期，不能证明生产部署已经修复。实际回归还需要在目标版本、真实适配层或调用封装中重复验证同一不变量。测试用例应同时覆盖正常输入和拒绝路径，否则"全部拒绝"的错误实现也可能被误当成安全修复。

五、研发与安全团队行动清单

P0：检查发布容器、Runner 镜像和开发机中的 gh 版本，升级到修复版；盘点使用 --source-ref 的脚本。无法立即升级时，按官方建议增加 --source-digest，并由可信审批流程提供提交值。

P1：检查目标仓库是否存在仅大小写不同的意外分支；对历史部署比对证书中的原始 ref 和已批准 commit。发现不一致先保留证明、策略、执行日志，再决定是否回滚，不把差异直接判为入侵。

P2：门禁测试加入大小写变体、正确分支错误提交、正确提交错误仓库、证明缺失等负向样例。将验证器版本纳入部署证据，避免构建镜像仍携带旧工具。

如何形成可复核的修复证据

研发负责提交调用点、配置差异和回归结果；平台团队负责证明新构建已部署到实际实例；安全团队复核前提是否消除，并保留未覆盖环境的清单。完成条件应落在运行中的版本与行为，而非工单状态或补丁合并时间。

建议对每个服务记录：组件实际版本、受影响功能是否启用、输入来源、修复负责人、部署批次及失败回滚方案。无需搜集完整敏感输入；用脱敏样本和配置摘要通常更适合审计。对于无法及时升级的实例，临时措施必须指定复核日期，避免长期漂移为默认设计。

六、总结

这项问题提醒我们：安全约束必须与最终执行语义一致。识别依赖版本、定位真实调用链、验证负向行为、确认部署完成，缺少任何一步都可能让修复停留在纸面。本文的工程建议用于补充系统设计，不应被误读为厂商已确认的额外攻击链。