process - 代码签名作为构建过程的一部分

Question

我想了解一些关于代码签名的最佳实践。我们有一个基于 Eclipse 的应用程序，并且认为对我们的插件进行签名是合适的。这引发了很多问题：

• 私钥可以/应该在源代码控制中吗？

• 我们应该将代码签名作为我们夜间构建过程的一部分还是作为我们发布过程的一部分？

• 代码是否应该自动签名，或者有理由为什么应该是手动步骤？

我倾向于说“是”、“每晚”和“自动”，但我可以看到只签署发布产品的论点。我什至可能会提出 SQA 应该在他们验证代码后对其进行签名的论点，尽管这确实会影响我们的发布过程。

其他人如何管理这个？

Answer 1

这取决于您希望您的私钥有多安全，它可能不是您希望具有源访问权限的临时员工拥有完全访问权限的东西。

在我的工作中，我们执行以下操作：

“测试签名”二进制文件作为我们日常构建的一部分，带有签入密钥。这需要在机器上安装测试根证书才能信任二进制文件，但如果这些位部署在公司外部，它们将不受信任。

每周（以及对于外部发布），我们使用真实密钥进行签名。这是通过一个单独的、有点手动的过程来完成的。只有少数人可以访问密钥来签署产品。

Answer 2

我可以告诉你我是如何看到这在一家大公司中完成的。个人开发人员可以构建代码，但他们不能签名。那将是一个私人构建。Contiguos 集成机器将丢弃使用存储在构建机器密钥库中的密钥签名的夜间构建，该密钥将是由公司证书颁发机构签名的测试密钥（即仅在公司内部受信任的密钥）。官方版本只能由具有官方、全球可信权威签名的受控机器签名，签名密钥存储在受控访问室的硬件模块中。

这个想法是，私钥实际上应该在世界上只有一个副本（最多一个额外的用于托管）。密钥的全部价值来自其隐私，而不是其他任何东西。您的整个组织都可以使用这一刻，就像把它放在海盗湾一样好。