4

我们最近购买了一个代码签名证书，并且我一直在将代码签名步骤合并到我们的自动化构建中。

我们的构建脚本必须构建 VB6 和 .NET 项目，因此我们目前有一个批处理文件来构建所有内容。对于 .NET 项目，我们的构建脚本调用 MSBUILD，传入一个解决方案文件进行构建。这些解决方案中的项目有一些第三方依赖项，并且这些文件都在References中打开了Copy Local选项，因为它们是运行应用程序所必需的。此外，一些项目使用 COM 互操作，因此它们具有自动生成的互操作程序集（例如Interop.MSXML2.dll），这些程序集也会在构建期间复制到输出文件夹。

我试图找出一个简单的代码签名在构建期间编译的文件（即我们的程序集），并忽略第三方库和互操作程序集，而不必分别在每个程序集上调用signtool.exe .

目前，我通过在构建脚本中执行以下操作来解决此问题：

  • 确保构建清除所有以前构建的文件
  • 使用 MSBUILD 编译 .NET 解决方案，为构建指定一个输出文件夹
  • 使用signtool.exe对输出文件夹中的所有二进制文件（EXE、DLL、OCX）进行递归签名。这会签署所有内容，包括第三方库和自动生成的互操作程序集
  • 我的第三方依赖项位于一个单独的lib文件夹中，因此我将所有文件从lib回复制到构建输出文件夹中，覆盖构建复制到那里的副本。这样这些文件不再被签名，但我们的程序集仍然是

我的问题是，有没有更好的方法来做到这一点？我能想到的唯一另一种选择是在每个需要签名的程序集上单独调用signtool.exe，但这可能会很痛苦，因为项目的数量和其中发生的更改量（程序集被重命名、移动、获取随着项目的发展而删除）。另外，我不想猜测特定程序集是否已签名，因此循环浏览文件并批量签名对我来说最有意义。

然而，与此同时，随意签署我们没有使用我们的代码签名证书创建的文件似乎是不正确的（在道德上、法律上或其他方面）。

或者也许我完全以错误的方式去做这件事？

4

1 回答 1

1

如果您拥有分发您所包含的所有库的许可证，那么我认为向它们添加您的数字签名不会成为问题。在创建您的安装程序之前，我只需签署所有内容。

也就是说，在用户的机器上对所有内容进行签名有一些好处，但最重要的是要签名的是您的安装程序——这是大多数用户看到数字签名有助于缓解的可怕消息的地方。

就构建而言 - 我使用 Visual Build Professional 来管理我的所有构建过程，它有一个集成的代码签名步骤，我用它来在复制所有内容时对其进行签名。我最长的部署项目总共有 300 多个步骤，从签名到上传都完成了。我与 Kinook 没有任何关系，但我尝试推广该软件 - 我无法想象它在给定的工作周内为我节省了多少时间。

于 2011-07-07T18:19:46.647 回答