如何避免在自动构建的 .NET 项目中对第三方库进行 Authenticode 签名？
我们最近购买了代码签名证书，并且我已将代码签名步骤合并到我们的自动化构建中。
我们的构建脚本必须构建 VB6 和 .NET 项目，因此我们目前有一个可以构建所有内容的批处理文件。对于 .NET 项目，我们的构建脚本调用 MSBUILD，传入要构建的解决方案文件。这些解决方案中的项目具有一些第三方依赖项，并且这些文件都在参考中打开了复制本地选项，因为运行应用程序需要它们。此外，某些项目使用 COM Interop，因此它们具有自动生成的 Interop 程序集（例如 Interop.MSXML2.dll），这些程序集也会在生成期间复制到输出文件夹。
我试图找出一种简单的方法来对构建期间编译的文件（即我们的程序集）进行代码签名，并忽略第三方库和互操作程序集，而无需调用分别在每个程序集上signtool.exe。
目前，我通过在构建脚本中执行以下操作来解决此问题：
- 确保构建清除所有先前构建的文件
- 使用 MSBUILD 编译 .NET 解决方案，指定构建的输出文件夹
- 递归地签署所有二进制文件（EXE、DLL） 、 OCX 的）在输出文件夹中使用 signtool.exe。这对所有内容进行了签名，包括第三方库和自动生成的互操作程序集。
- 我的第三方依赖项位于单独的
lib文件夹中，因此我从lib复制所有文件> 回到构建输出文件夹，覆盖构建复制到那里的副本。这样这些文件不再被签名，但我们的程序集仍然是
我的问题是，有没有更好的方法来做到这一点？我能想到的唯一的其他选择是在每个需要签名的程序集上单独调用 signtool.exe ，但这可能会很痛苦，因为项目的数量以及其中发生的更改量（随着项目的发展，程序集会被重命名、移动、删除）。另外，我不想猜测特定程序集是否已签名，因此循环遍历文件并批量签名对我来说最有意义。
然而，与此同时，任意签署我们没有使用代码签名证书创建的文件似乎并不正确（道德上、法律上或其他方面）。
或者也许我完全以错误的方式处理这个问题？
We recently purchased a code-signing certificate and I've been incorporating the code signing step into our automated builds.
Our build script has to build both VB6 and .NET projects, so we currently have a batch file that builds everything. For the .NET projects, our build script calls MSBUILD, passing in a solution file to build. The projects in these solutions have some third-party dependencies, and these files all have the Copy Local option turned on in References, since they are needed to run the application. In addition, some projects use COM Interop, and so they have automatically-generated Interop assemblies (such as Interop.MSXML2.dll) that are also copied to the to the output folder during a build.
I'm trying to figure out an easy to only code sign the files that are compiled during the build (i.e. our assemblies), and ignore third-party libraries and Interop assemblies, without resorting to having to call signtool.exe on each assembly separately.
Currently, I worked around this by doing the following in the build script:
- Make sure the build cleans all previously-built files
- Compile the .NET solution with MSBUILD, specifying an output folder for the build
- Recursively sign all of the binaries (EXE's, DLL's, OCX's) in the output folder with signtool.exe. This signs everything, including the third-party libraries and auto-generated Interop assemblies
- My third-party dependencies are in a separate
libfolder, so I copy all of the files fromlibback into the build output folder, overwriting the copies that the build copied there. This way these files are no longer signed, but our assemblies still are
My question is, is there a better way to do this? The only other alternative I can think of is to call signtool.exe individually on each assembly that needs signing, but this could be a pain because of the number of projects and the amount of change occurring in them (assemblies get renamed, move, get deleted as the projects evolve). Plus, I don't want to have to guess whether a particular assembly got signed or not, so looping through the files and signing them in bulk makes the most sense to me.
At the same time, however, it doesn't seem right (morally, legally, or otherwise) to arbitrarily sign files that we didn't create with our code-signing certificate.
Or maybe I'm going about this the wrong way altogether?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您拥有分发您所包含的所有库的许可证，那么我认为向其中添加您的数字签名不会成为问题。我只是在创建安装程序之前签署所有内容。
也就是说，在用户计算机上对所有内容进行签名有一些好处，但最重要的签名是您的安装程序 - 这是大多数用户看到数字签名有助于缓解的可怕消息的地方。
就构建而言 - 我使用 Visual Build Professional 来管理我的所有构建过程，它有一个集成的代码签名步骤，我用它来对复制的所有内容进行签名。我最长的部署项目总共超过 300 个步骤，涵盖了从签名到上传的所有内容。我与 Kinook 没有任何关系，但我尝试推广该软件 - 我无法想象它在给定的工作周内为我节省了多少时间。
If you have license to distribute all of the libraries you're including then I don't think adding your digital signature to them is going to be a problem. I'd just sign everything before creating your installer.
That said, there are some benefits to having everything signed on the user's machine but the most important thing to sign is your installer - that's where most users see the scary messages that a digital signature helps mitigate.
As far as building goes - I use Visual Build Professional to manage all of my build processes and it has an integrated code signing step that I use to sign everything as it is copied. My longest deployment project is over 300 steps in total and does everything from signing to uploading. I'm not associated with Kinook but I try to promote the software - I can't imagine how much time it saves me in a given work week.