OpenBao项目取消强制提交签名要求的分析与决策

背景介绍

OpenBao作为一款安全产品，其代码仓库管理策略一直备受关注。近期项目团队经过深入讨论，决定调整原有的强制提交签名要求，这一决策背后蕴含着对开发者体验与安全实践的重新思考。

原有签名机制的问题

OpenBao原本要求所有Git提交必须使用GPG或SSH密钥签名，这一机制旨在验证提交者身份。但实际运行中暴露出多重问题：

1. 技术门槛过高：新贡献者需要花费额外时间配置签名环境，这对社区参与度造成负面影响。

2. 签名验证的局限性：

   • GitHub平台存在签名时效性问题，当用户删除SSH密钥后，历史提交的"已验证"状态会变为"未验证"
   • 使用rebase合并时，GitHub存在长期未修复的bug导致所有签名失效
   • 缺乏有效的信任链验证机制，无法真正检测账户是否被入侵

3. 工作流冲突：项目采用"Squash and Merge"策略时，GitHub会使用自己的密钥重新签名，使得原始提交签名失去意义。

安全风险再评估

经过深入讨论，团队重新评估了签名机制的实际安全价值：

1. 有限的防护效果：攻击者若获取账户会话cookie（但无2FA权限），理论上可提交未签名PR，但这种情况极为罕见且PR仍需审核。

2. 更有效的替代方案：直接推送保护、严格的PR审核流程比提交签名更能防范恶意代码。

3. 签名验证的信任基础薄弱：GitHub托管的签名验证本质上是"GitHub说可信"，缺乏真正的信任链验证。

折中解决方案

最终团队采取了平衡方案：

1. 取消全局强制签名：移除了分支保护规则中的签名要求，降低贡献门槛。

2. 核心维护者特殊要求：通过GitHub Actions工作流，确保维护者的提交仍需签名。

3. 保留DCO要求：开发者证书来源(DCO)签名要求保持不变，这是与代码签名不同的验证机制。

行业实践参考

这一决策参考了多个知名安全项目的实践：

• OpenSSL等高度合规项目也未强制要求提交签名
• Kubernetes采用机器人合并机制而非依赖提交签名
• 多数安全认证标准(FIPS、Common Criteria等)并不强制要求提交签名

总结

OpenBao的这一调整体现了安全实践中实用主义与理想主义的平衡。通过取消全局签名要求但保留对核心维护者的验证，项目在降低贡献门槛的同时，仍保持了合理的安全水位。这一案例也展示了安全策略需要根据实际威胁模型和开发者体验不断优化，而非机械套用"最佳实践"。