Antivirus problems during installation of WixSharp built MSIs

[LarsRadmans]

Hi Oleg,
is seems the antiviruses continues to haunt Wix & WixSharp ... 🙄

This time the problem circles around the temp files that the MSI installer unpacks and executes under the temporary folder created in user %TEMP%. Like the WixSharp.UI.dll and others that are put there temporarily.

I'm wondering if it would be possible to put a code signing hook into WixSharp so these files also could be code signed during the MSI build process (hopefully pleasing the AVs)? Something like what you have already done with the IDigitalSignature interface, but for these "internal" files?

Best regards,
Lars

[oleg-shilo]

Such a hook already exists. You can sign all files as long as you have an appropriate signing certificate.
See this wiki section: https://github.com/oleg-shilo/wixsharp/wiki/Tips'n'Tricks#how-to-sign-all-wixsharp-dlls

This is a quick illustration

Compiler.SignAllFilesOptions.SkipSignedFiles = true;
...
project.DigitalSignature = new DigitalSignature
                {
                    PfxFilePath = "wixsharp.pfx",
                    Password = "my_password",
                    Description = "MyProduct",
                    TimeUrl = new Uri("http://timestamp.verisign.com/scripts/timstamp.dll")
                }
project.SignAllFiles = true;

And this is a great discussion on signing with Azure Trusted Signing

[LarsRadmans]

I tried that one, but it seems to sign the files included in the installation package for the target PC, plus the MSI itself, but not the temporary files in use during the execution of the MSI. Like for instance WixSharp.UI.dll and DLLs containing custom actions. It is those temporary ones that the antivirus react on, and I would like to get them signed too.

[oleg-shilo]

You are right.
I rechecked and found that project.SignAllFiles = true; only signs the user-supplied files but not WixSharp assemblies.
I will extend the signing algorithm to cover WixSharp too.

Changing this ticket to the feature request...

[LarsRadmans]

Thank you! 🙏🏼

[oleg-shilo]

Done. Will be available in teh very next release:

While you do not need to do anything to activate the new feature, you can disable it if you prefer the pre-fix functionality.

Compiler.SignAllFilesOptions.SignEmbeddedAssemblies = false; // the default is true 

I also added a convenient generic class to avoid bulky inheritance:

  project.DigitalSignature = new GenericSigner
         {
             Implementation = (file) =>
             {
                 byte[] unsignedContent = IO.File.ReadAllBytes(file);
                 byte[] signedContent = SigningService.Sign(unsignedContent); // is a made up service
        
                 IO.File.WriteAllBytes(file, signedContent);
                 return 0;
             }
         };

[oleg-shilo]

Done. Release v2.8.0

[LarsRadmans]

Hi!
I have finally gotten around to test this. I'm calling signtool.exe in my IDigitalSignature.Apply() implementation but it seems like the Wix*.DLL files that I'm trying to sign are locked by the calling WixSharp program ("installer.exe"). This is the signtool output:

SignTool Error: The file is being used by another process.
SignTool Error: An error occurred while attempting to sign: D:\agent\_work\333\b\installer\WixSharp.UI.dll

I added a Win32 restart manager process lookup test in the beginning of my Apply() to verify this, and it logs:

File is locked by 9312 'Installer'

It seems to me the WixSharp code has not closed all file handles when Apply() is called. Do you have any idea what this can be about?

Regards,
Lars

PS. Please see LinkedIn! DS.

[oleg-shilo]

Lars, this is because another process is your setup builder that you are running (program.cs).
Basically, the assembly wants to sign itself while it is running.
If it is what you want, then you need to rethink the strategy.
There are no great options that I can think of, but you can skip signing yourself in the event handler and instead sign the setup builder assembly before you run it.

Not an elegant solution, but it will work.

[oleg-shilo]

To minimize the impact of the the new feature I have updated the implementation of embedded assembly signing: 0361f3c:

• Compiler.SignAllFilesOptions.SignEmbeddedAssemblies default value is changed to false
• Updated property documentation to indicate that the file can be locked and to suggest a workaround