代码签名作为构建过程的一部分
我想了解一些有关代码签名的最佳实践。我们有一个基于 Eclipse 的应用程序，并且认为对我们的插件进行签名是合适的。这引发了很多问题：
私钥可以/应该在 源代码控制？
我们是否应该对代码进行签名作为 我们的夜间构建过程或作为一部分 我们的发布流程？
代码是否应该签名 自动地，或者有一个原因 为什么这应该是手动步骤？
我倾向于说“是”、“每晚”和“自动”，但我可以看到仅签署发布产品的争论。我什至可能认为 SQA 应该在验证代码后对代码进行签名，尽管这确实会扰乱我们的发布流程。
其他人如何处理这个问题？
I'd like to understand some of the best practices with respect to code signing. We have an Eclipse-based application and think it would be appropriate to sign our plug-ins. This raised a lot of questions:
Can/Should the private key be in
source control?Should we sign the code as part of
our nightly build process or as part
of our release process?Should the code be signed
automatically, or is there a reason
why that should be a manual step?
My inclination is to say, "Yes", "Nightly", and "Automatically", but I could see an argument for only signing the release products. I might even make the argument that SQA should sign the code after they have verified it, although that would really mess with our release process.
How do other people manage this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于您希望私钥的安全程度，您可能不希望具有源访问权限的临时员工拥有完全访问权限。
在我的工作中，我们执行以下操作：
使用签入密钥“测试签名”二进制文件作为我们日常构建的一部分。这需要机器上有一个测试根证书才能信任二进制文件，但如果这些位部署在公司外部，则它们将不受信任。
每周（以及外部发布），我们使用真实密钥进行签名。这是通过一个单独的、有点手动的过程完成的。只有少数人有权访问对产品进行签名的密钥。
It depends on how secure you want your private key to be, it might not be something that you want a temporary employee with source access to have full access to.
At my work, we do the following:
"Test sign" binaries as part of our daily builds with a checked in key. This requires a test root certificate to be on machines in order to trust the binaries, but they will not be trusted if the bits are deployed outside the company.
Weekly (and for external releases), we sign with the real key. This is done via a separate, somewhat manual process. Only a few people have access to the key to sign the product.
我可以告诉你我是如何在一家大公司中看到这一点的。个人开发人员可以构建代码，但无法对其进行签名。那将是私人建筑。 Contiguos 集成机器将丢弃使用构建机器密钥库中存储的密钥签名的夜间构建，该密钥将是由公司证书颁发机构签名的测试密钥（即仅在公司内部受信任的密钥）。官方版本只能由具有官方全球可信机构签名的受控机器进行签名，签名密钥存储在受控访问室的硬件模块中。
这个想法是，私钥在世界上实际上应该只有一份副本（最多额外一份用于托管）。密钥的全部价值源自其隐私，而不是其他任何东西。这一刻可供您的整个组织使用，就像把它放在海盗湾一样。
I can tell you how I've see this being done in a big corp. Individual developers could build the code, but they could not sign it. That would be a private build. Contiguos integration machine would drop nightly builds signed with a key stored on the build machine keystore, which would be a test key signed by a corporate certificate authority (ie. a key trusted only within the corp). The official build could be signed only by controlled machines with the official, global trusted authority signed, signature key stored in hardware modules in controled access room.
The idea is that a private key should realy have only one copy in the world (at most one extra for escrow). The whole value of the key is derived from its privacy, not from anything else. The moment is available to your entire org, is as good as putting it out on pirate bay.