How can I avoid Authenticode signing third-party libraries in a .NET project in an automated build?

4
votes

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 lib folder, so I copy all of the files from lib back 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?

1
.netmsbuildcode-signingauthenticode

1 Answers

1
votes

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.