#1204 Missing Files and Public Key Mismatches

[Christopher Painter]

3.0.4116.0/

wix3.msi and wix3-binaries.zip

SDK\MakeSfxCA.exe missing
Assemblies PublicKey ce35f76fcda82bad AssemblyVersion 3.0.0.0

wix3-sources.zip
src\DTF\Libraries\Compression\Compression.cd is missing
src\DTF\Libraries\Compression.Cab\Errors.Resources.resources is missing
src\DTF\Libraries\WindowsInstaller\Errors.Resources.Resources is missing
src\DTF\Libraries\WindowsInstaller\WindowsInstaller.cd is missing

wix3-sources libraries build with PublicKey 36e4ce08b8ecfb17

If I build the MakeSfxCA manually and try to make a sample project using SDK DLL's from WiX3.msi I get a custom action build error:

Error 1 System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Deployment.Resources, Version=3.0.0.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) C:\data\Sandbox-CommonInstaller\CustomActions\EXEC CustomActions

If I build the DLL's manually ( slightly problematic because of missing files ) I can make the error go away.

Aside Concern: If I drop the DLL's into the GAC the problem also goes away. If someone was to make a rogue version of the DLL's and deploy them to a users GAC, couldn't this inject a man in the middle attack on the custom action hosting model?

[Jason Ginchereau]

Logged In: YES
user_id=2086430
Originator: NO

The missing files will be in the next build. I'll close this bug at that time.

The public key mixup is caused by building some binaries locally while using other binaries from the published build. (The key pair used by developer builds is different than that used for published builds.) So that problem should be resolved by using all published binaries, which will be possible when they're all there.

Injecting rogue DLLs in the GAC is not much of a threat, for two reasons:

1. The binaries in the published WiX builds are signed with a private key that is kept secure and not available publicly. So as long as you ship your setup with a regular published WiX build, nobody can impersonate an assembly in the GAC because they won't be able to create an assembly with the same public key.

A different, development-only non-secure key pair is provided with the published sources, just for convenience so developers can build successfully. You should not ship binaries built with that key! If you want to ship a custom build, you should replace the development key pair with your own secure key.

1. Installing or modifying anything in the GAC requires administrator privileges on the system. If somebody has admin privileges, then they already have complete control and there are plenty of malicious activities they could do that are easier and/or worse than replacing an interop DLL in the GAC.