Git 提交签名的三个月研究：签了不等于验了

当天发生了什么

2026-08-29 14:07（UTC），Abubakar Sadiq Shittu、John Sadik 与 Scott Ruoti 在 arXiv 提交了论文《A Multi-Month Study of Git Commit Signing》v1。研究为期三个月，22 名高年级本科生与研究生作为初级开发者的代表，完成签名配置、在四个课程项目中使用、扩展到第二台设备、检查一个含异常提交的外部仓库，并回答安全推理问题。结果显示：几乎所有参与者都签署了每次提交，对日常签名评价正面；但很多人在配置、多设备和仓库验证上遇到困难；超过四分之一的人没有发现异常提交；近一半的人对签名保证或密钥管理至少有一项误解。

对保护应用逻辑意味着什么

这和应用保护的关系在于构建链。混淆配置、keep 规则、签名脚本这些文件决定了发出去的包受到多少保护，一次未经审查的修改就可能悄悄关掉某项保护，或加入一条宽泛规则。提交签名可以提供来源信息，但论文提醒：签名的价值取决于有人对照授权身份去验证，并正确理解「缺少签名」和「未知密钥」意味着什么。只开启签名而不验证，安全感多于安全性。限制方面，参与者是学生，结果不能直接外推到有经验的团队，论文也未区分困难来自工具、教育还是理解。

可以做的检查

在受保护分支上要求签名提交，并在 CI 中对照团队维护的授权密钥列表做验证，而不是只检查「有签名」。把混淆配置、keep 规则、签名与公证脚本列为需要指定负责人审查的文件，例如通过 CODEOWNERS。为密钥轮换、设备丢失和成员离开制定书面流程。定期抽查发布构建对应的提交来源，确认保护配置的每次变化都有可追溯的审批记录。同时要记住，缺少签名或出现未知密钥都是需要调查的信号，而不是可以直接放过的情况。

行动清单

• CI 中对照授权密钥列表验证提交签名
• 为保护相关配置文件指定审查负责人
• 制定密钥轮换与人员变动流程