我想了解有关代码签名的一些最佳做法。我们有一个基于 Eclipse 的应用程序，并且认为对我们的插件进行签名是合适的。这引发了很多问题：
私钥可以/应该在 源代码控制？
我们是否应该签署代码作为 我们的夜间构建过程或作为一部分 我们的发布过程？
代码是否应该签名 自动，还是有原因 为什么这应该是手动步骤？
我倾向于说“是”、“每晚”和“自动”，但我可以看到只签署发布产品的论点。我什至可能会提出 SQA 应该在他们验证代码后对其进行签名的论点，尽管这确实会扰乱我们的发布过程。
其他人如何管理这个？
【问题讨论】：
标签： process eclipse-plugin code-signing
这取决于您希望您的私钥有多安全，它可能不是您希望具有源访问权限的临时员工拥有完全访问权限的东西。
在我的工作中，我们执行以下操作：
“测试签名”二进制文件是我们日常构建的一部分，带有签入密钥。这需要在机器上安装测试根证书才能信任二进制文件，但如果这些位部署在公司外部，它们将不受信任。
每周（以及对于外部版本），我们使用真实密钥进行签名。这是通过一个单独的、有点手动的过程来完成的。只有少数人可以使用密钥来签署产品。
【讨论】：
我可以告诉你我是如何看到这在一家大公司完成的。个人开发人员可以构建代码，但他们不能签名。那将是一个私人构建。 Contiguos 集成机器将丢弃使用存储在构建机器密钥库中的密钥签名的夜间构建，该密钥将是由公司证书颁发机构签名的测试密钥（即仅在公司内部受信任的密钥）。官方版本只能由具有官方、全球可信权威签署的受控机器签名，签名密钥存储在受控访问室的硬件模块中。
这个想法是，一个私钥实际上应该在世界上只有一个副本（最多一个额外的用于托管）。密钥的全部价值来自其隐私，而不是其他任何东西。您的整个组织都可以使用这一刻，就像把它放在海盗湾一样好。
【讨论】：