代码之家  ›  专栏  ›  技术社区  ›  Chris Arguin

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

  •  5
  • Chris Arguin  · 技术社区  · 15 年前

    我想了解一些关于代码签名的最佳实践。我们有一个基于Eclipse的应用程序,并且认为应该对插件进行签名。这提出了许多问题:

    • 私钥是否可以 源代码控制?

    • 我们要在代码上签名吗 我们的夜间建造过程或作为一部分 我们的发布过程?

    • 代码应该签名吗 自动的,还是有原因的 为什么这应该是手动步骤?

    我倾向于说“是的”、“夜间的”和“自动的”,但我可以看到只有在发布产品上签名的论点。我甚至可能会提出这样的论点,即SQA应该在验证代码之后签署代码,尽管这会真正影响我们的发布过程。

    其他人如何管理这个?

    2 回复  |  直到 15 年前
        1
  •  7
  •   Michael    15 年前

    这取决于您希望您的私钥有多安全,它可能不是您希望具有源代码访问权限的临时员工具有完全访问权限的内容。

    在我的工作中,我们做以下工作:

    “测试签名”二进制文件是我们日常构建的一部分,带有一个签入键。这要求在计算机上有一个测试根证书,以便信任二进制文件,但是如果这些位部署在公司外部,它们将不受信任。

    每周(对于外部版本),我们用真正的密钥签名。这是通过一个单独的,有些手动的过程来完成的。只有少数人可以使用密钥签署产品。

        2
  •  4
  •   Remus Rusanu    15 年前

    我可以告诉你我是如何在一个大公司里看到这一点的。单个开发人员可以构建代码,但他们不能签署它。那将是一个私人建筑。ContinuOS集成计算机将删除使用存储在生成计算机密钥库上的密钥签名的夜间生成,该密钥将是由公司证书颁发机构(即仅在公司内部受信任的密钥)签名的测试密钥。官方版本只能由受控机器签署,并由官方、全球可信授权机构签署,签名密钥存储在控制访问室的硬件模块中。

    其想法是,一个私钥在世界上应该只有一个副本(最多一个额外的托管)。密钥的整个值是从它的隐私中派生出来的,而不是从其他任何东西中派生出来的。这个时刻对你的整个组织都是可用的,就像把它放到海盗湾一样。