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

Question

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

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

• 我们是否应该将代码签署为 我们每晚的构建过程或作为一部分 我们的发布流程？

• 代码是否应该签名 自动，还是有原因的 为什么这应该是一个手动步骤？

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

其他人如何管理这个？

Answer 1

这取决于您希望私钥的安全程度，您可能不希望具有源访问权限的临时员工具有完全访问权限。

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

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

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

Answer 2

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

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