在 GitHub 上伪造已签名提交
GitHub 使用基于正则表达式的提交元数据解析器，导致一种可利用的漏洞：攻击者通过让 Git 与 GitHub 对 author 字段的解释不同步，伪造出“GitHub 已验证”的签名提交。评论者认为，这体现了在安全敏感代码中临时解析和解析器不匹配的风险，并呼吁改用 Git 自己的库或更严格、按规范驱动的解析器。该事件也进一步加剧了人们对签名提交、GitHub 管理的签名，以及最初淡化此类报告的漏洞分流流程的安全价值的怀疑。
根本原因：正则表达式 vs. 正确解析
- 许多评论者认为，这是“不要用临时拼凑的正则表达式去解析结构化格式”的教科书式案例，尤其是在安全关键代码中。
- 另一些人强调，更深层的问题是 解析器不匹配：GitHub 的自定义正则逻辑与 Git 自己的解析器对“什么是有效内容”存在分歧，从而可以发动不同步攻击。
- 有几位认为，唯一真正安全的做法是复用 Git 自己的实现（或 libgit2），而不是重新实现解析。
- 也有人为正则表达式辩护，前提是它用于小范围、明确限定、分步骤的检查（例如先定位
author行，再严格验证格式，并对任何异常情况直接失败）。
规范、验证与 Postel 定律
- 评论者批评这次修复只是“调整一下正则”，而不是正经地规定提交头格式，并用严格解析器来强制执行。
- 更安全的模式被建议为：一旦出现多个
author行、格式错误的行，或任何意外情况，就立即失败。 - Postel 鲁棒性原则（“对所接受的内容要宽松”）受到猛烈批评，被认为与现代安全性不相容；宽松解析会把别人的坏输入变成你自己的问题。
- 也有人指出，Postel 定律在早期互联网互操作性上曾经有帮助，但如今对安全敏感组件来说很危险。
GitHub 签名提交的含义与价值
- 有些人把“由 GitHub 的已验证签名签名”视为等同于未签名，因为那不是作者自己的密钥。
- 另一些人认为它有价值：它证明该提交是通过 GitHub 的网页界面或 Codespaces，在已认证账户下产生的，并提供一个可信时间戳——在某些供应链和回溯时间戳场景中很有用，前提是 GitHub 没有被攻破。
- 对于 GitHub 将提交者重写为自己，以附加已验证徽章，很多人感到困惑和不满；批评者认为这污染了 Git 元数据，支持者则说这符合 author/committer 模型（工具或维护者代表作者操作）。
- 用同一个签名密钥服务所有用户，被认为会放大这类 bug 的影响范围。
签名提交：用途与实际痛点
- 有些人认为签名提交基本没什么意义：如果攻击者能推送代码，他们通常也能签名。
- 另一些人强调其在缓解供应链风险方面的作用，但前提是密钥信任确实有意义（PGP Web of Trust、域名托管密钥，或平台托管密钥）。
- 配置和工具链被认为很麻烦，不过也有人提到基于 SSH 的签名和密码管理器集成让流程更容易一些。
- 大家都认同，盲签名端点（例如 Codespaces 可以签名任意提交）会显著增加复杂度和攻击面。
安全流程与透明度
- 一些评论批评 GitHub（以及大公司）的漏洞分流：大量低质量报告带来的噪声，使得初级员工会把真实问题以“这不是 bug”为由关闭。
- 轶事显示，一些组织会把严重发现驳回为“预期行为”，直到监管机构或公开曝光介入。
- 还有人指出，GitHub 迅速关闭安全问题的做法，以及缺乏详细的公开事后分析（包括该 bug 是否曾被利用），令人担忧。