Go 1.26 的“加密风暴”：当 Hashicorp Vault 的合规需求，撞上 Go 团队的安全哲学
💡
原文中文，约3700字，阅读约需9分钟。
📝
内容提要
Go 1.26计划废除crypto包中的rand io.Reader参数，遭Hashicorp Vault开发者强烈反对，认为此变更影响HSM和FIPS合规性。Go安全团队回应称安全性优先，复杂需求不应影响标准库设计，最终坚持设计哲学，确保crypto库更安全、清晰。
🎯
关键要点
- Go 1.26计划废除crypto包中的rand io.Reader参数，引发Hashicorp Vault开发者强烈反对。
- Hashicorp Vault开发者认为此变更影响HSM和FIPS合规性，可能导致核心功能失效。
- Go安全团队坚持安全性优先，认为复杂需求不应影响标准库设计。
- Filippo Valsorda指出，Vault的需求在安全角度上毫无意义，增加复杂性反而带来更多风险。
- Go团队强调标准库的职责是为大多数用户提供安全、简单的API，而不是满足少数合规需求。
- 辩论中提到的确定性密钥生成应有明确的规范，而不是滥用随机性参数。
- Go团队采取家长式安全策略，默认提供最安全的选项，逐步移除误用的高级选项。
- API设计应清晰，避免参数被滥用，必要功能应设计专门的API。
- Go团队通过GODEBUG环境变量提供过渡期，帮助用户适应破坏性变更。
- 最终，Go团队坚持设计哲学，确保crypto库更安全、清晰，长远受益于整个Go生态。
❓
延伸问答
Go 1.26的变更对Hashicorp Vault有什么影响？
Go 1.26计划废除crypto包中的rand io.Reader参数，导致Hashicorp Vault无法满足HSM和FIPS合规性，影响其核心功能。
Go安全团队为何坚持不满足Hashicorp Vault的需求？
Go安全团队认为复杂需求不应影响标准库设计，强调安全性优先，确保crypto库更安全、清晰。
Filippo Valsorda对Hashicorp Vault的需求有什么看法？
Filippo认为Vault的需求在安全角度上毫无意义，增加复杂性反而带来更多风险。
Go团队如何处理破坏性变更的过渡期？
Go团队通过GODEBUG环境变量提供过渡期，帮助用户适应破坏性变更，通常为期两年。
Go团队对API设计有什么原则？
Go团队强调API设计应清晰，避免参数被滥用，必要功能应设计专门的API。
这场辩论对Go社区有什么启示？
辩论提醒Go社区理解安全哲学，重视清晰的API设计，并利用GODEBUG管理变更。
➡️
