如何避免在自动构建的 .NET 项目中对第三方库进行 Authenticode 签名？

Question

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

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

我试图找出一种简单的方法来对构建过程中编译的文件（即我们的程序集）进行代码签名，并忽略第三方库和互操作程序集，而无需分别在每个程序集上调用signtool.exe。

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

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

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

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

或者也许我完全以错误的方式处理这个问题？

Answer 1

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

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

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