Search code examples
c++visual-studiomsbuilddriverdigital-signature

MSBuild detect if signed driver is same as previous built non-signed driver (prevent re-signing via caching)


My organization has a driver that now needs to be signed by both our organization and by Microsoft.

We have a build process that runs on windows as a batch file, it runs msbuild for all of the binaries and it would sign the binaries with our organization certificate.

As of recently we have to start signing the binary with a microsoft certificate as well, in order to achieve this we have to build a .cab file, sign the .cab, and send that to microsoft with a special tool. Microsoft then signs the file and we can download a .cab which contains the driver that has both signatures.

The problem is this signing process with microsoft is very time consuming, and we have several drivers for several versions of windows that all need to be signed. These drivers hardly ever change so we should be able to cache them and re-use them from previous builds.

We would like our build system to work the same locally as it does on the build server, that is, all you have to do is run the build batch file and it should perform an opportunistic rebuild, reusing binaries wherever possible (only caching locally, no need for network caching).

msbuild can obviously detect whether binaries need to be rebuilt and do so opportunistically, avoiding rebuild when the source/inputs haven't changed.

The issue is, after we build with msbuild, the signing step takes place with a custom script.

We were hoping that the signed binary would not appear as a 'different binary' and msbuild would consider the build 'up to date' when it sees the fully signed binary in the output location, but this isn't the case. Instead, msbuild rebuilds the binary and overwrites the signed version with an unsigned version, and this in turn triggers the signing process again.

How can we properly cache the signed binary in builds?


Solution

  • Copying my comment to a solution, not sure if this is appropriate as a solution as it was a bit of a compromise.

    In the end our solution is to check if:

    a) the built binary changed timestamp as a result of msbuild.exe, or b) the path of the signed binary is older than the built binary

    If either A or B is true then copy and sign the built binary to the path of the signed binary.

    We cannot sign the 'built file' until it is copied to the signed path, otherwise it will always get updated each time msbuild runs.