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