.net - 如何在自动构建中避免 .NET 项目中的 Authenticode 签署第三方库？

Question

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

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

我试图找出一种易于仅对构建期间编译的文件(即我们的程序集)进行代码签名的方法，并忽略第三方库和互操作程序集，而不必求助于 signtool.exe 分别在每个组件上。

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

确保构建清除所有以前构建的文件

使用 MSBUILD 编译 .NET 解决方案，为构建指定输出文件夹

使用 对输出文件夹中的所有二进制文件(EXE、DLL、OCX)进行递归签名signtool.exe .这会对所有内容进行签名，包括第三方库和自动生成的互操作程序集

我的第三方依赖项位于单独的 lib 中文件夹，所以我复制了 lib 中的所有文件回到构建输出文件夹，覆盖构建复制到那里的副本。这样这些文件不再被签名，但我们的程序集仍然是

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

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

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

Answer 1

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

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

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