新研究：经过“验证”的GitHub提交并非唯一

# 新研究：“已验证”的 GitHub 提交并非唯一 来源：https://www.internationalcyberdigest.com/new-research-a-verified-github-commit-is-not-unique/ Git 通过内容的哈希值来标识每个对象，对于一次提交，该哈希值覆盖了树结构、元数据、消息以及任何签名的原始字节。大量供应链机制将这个哈希值视为特定签名内容的唯一、不可变名称。持续集成流水线依赖它进行固定，依赖管理器通过它锁定，事件响应者根据它进行阻断或回滚。 卡内基梅隆大学的 Jacob Ginesin 发布了一篇新的预印本（https://arxiv.org/abs/2607.02820?ref=internationalcyberdigest.com），认为这一假设存在漏洞。根据该论文，对于任何已签名的提交，没有签名密钥的攻击者都可以生成第二个不同的提交，该提交具有完全相同的树结构、元数据、有效签名以及来自 GitHub 等平台的“已验证”标记。唯一改变的是提交哈希值。由于每个提交通过哈希值引用其父提交，这种改变会沿着链向下传递，作者称之为“哈希链可塑性”。 该机制是**签名可塑性**（https://github.com/JakeGinesin/git-chain-malleator?ref=internationalcyberdigest.com），而非哈希函数被攻破。论文明确指出，它并不展示两个不同内容共享同一个哈希值，因此该发现与 SHA-1 的抗碰撞性或 Git 正在迁移的 SHA-256 无关。实际上，一个逻辑上的提交可以对应许多字节不同但同样有效的签名序列化形式，每种形式哈希值都不同。 论文描述了三种路径，覆盖了 GitHub 验证的所有基于 GPG 的方案。对于 ECDSA，它利用了经典的代数对称性，将签名 (r, s) 变成同样有效的 (r, n-s)。对于 RSA 和 EdDSA，由于无法使用该技巧，它会在 OpenPGP 签名数据包的未哈希区域中附加一个格式正确但被忽略的子数据包，而 RFC 4880 指出该区域不受签名保护。对于 S/MIME，它将对 CMS 结构中的长度字段进行重新编码，变为非规范形式，这种形式在严格 DER 中无效但作为 BER 仍能被接受。 论文指出，将这些本地奇异性转化为供应链问题的是 GitHub 的服务端行为。根据研究，GitHub 在验证前不会对签名容器进行规范化处理，因此它接受 ECDSA 反转、OpenPGP 子数据包插入以及非规范 S/MIME 编码，并为每个由此产生的提交分配一个以提交哈希为键值的持久“已验证”记录。GitHub 自己的文档也证实了该底层功能：提交的验证状态基于验证时创建的记录保留，即使签名密钥后来被撤销或过期。论文指出，严格的本地验证则更为混杂。`git verify-commit` 接受两种 OpenPGP 路径，但拒绝非规范 S/MIME 编码，而 GitHub 却仍会接受该编码。 --- --- 国际网络安全文摘 ### 获取 ICD 通讯 订阅以获取来源驱动的网络安全新闻、OSINT 笔记、漏洞更新和分析。有证据或线索？请发送给 ICD。 --- ##### 订阅 获取 ICD 通讯：网络安全新闻、OSINT 笔记、来源和分析。 太好了！请查看您的收件箱并点击链接 请输入有效的电子邮件地址！