Signing Bootstrapper Pieces

Apr 6, 2016 at 5:13 PM
In our current code, we have an uncompressed silent bootstrapper containing our msi and our dotNet dependency. After creating the bundle, we sign the msi and the bootstrapper files, move them, and pass them on. The issue is that it appears that signing the msi is causing the hash to change, such that the bootstrapper refuses to launch it and exits with the log saying

e000: Error 0x80091007: Hash mismatch for path:
e000: Error 0x80091007: Failed to verify hash of payload:
e310: Failed to verify payload:
e000: Error 0x80091007: Failed to cache payload:
e314: Failed to cache payload:

My suspicion is that we probably need to sign the msi before creating the bootstrapper, but given that our signing tool doesn't live in the same process (signing occurs as part of a separate process that handles release prep so that every debug build does not have to go through all the extra steps while the msi and bootstrapper creation occur in one big move) I would like to know if 1) We can somehow update the hash using Wix# 2)We can create the msi and then after the signing build the bootstrapper (thus only creating the bootstrapper when we relase an updated version of our code) or 3) If we just have to move our signing tool into our main project and start signing the msi as it gets built. Do any of these sound like solutions to our issue, or do you have any other insights into why signing the msi after adding it to the bundle is causing an error?

Thank You
Coordinator
Apr 7, 2016 at 2:03 AM
While I do not have a full knowledge of the signing model Burn is using I would expect that your final bootstrapper supposed to be built when your included MSIs are fully signed. Thus I think your suspicion is most likely correct.

Wix# doesn't do much about signing. I only provided an external task isolated wrapper ('Signing' sample) for the sign tool. And this wrapper isn't particularly comprehensive as it is nothing else but a command line builder for invoking 'signtool.exe' :
int exitCode = Tasks.DigitalySign(msi_file,
                                  "wixsharp.pfx",
                                  "http://timestamp.verisign.com/scripts/timstamp.dll",
                                  "my_password");
As you can see signing is completely outside of building MSI with Wix# and it can be triggered at any time after Wix# is done with authoring the MSI file. Thus updating the hash using Wix# may be as simple as executing Tasks.DigitalySign again.

Though your options #2 seems to me the most logical as it is consistent with Wix# breaking authoring in four fully decoupled stages:
  1. Build MSIs
  2. Sign MSIs (optional)
  3. Build Bootstrapper
  4. Sign Bootstrapper (optional)
Though #3 may be just more practical as it may attract less changes in the current procedure.

If you end up using Wix# signing keep in mind that you can pass the location of the 'signtool.exe' to the Tasks.DigitalySign as the last optional param wellKnownLocations. You may even get away with the network location of the signtool providing your build machine policies allows network executables to be run.

Good luck