heat.exe and fips

[wixbot]

Request a command line argument to pass -fips through heat. Heat throws the following error which could be corrected by passing the fips switch through heat and then into: Microsoft.Tools.WindowsInstallerXml.Common.GenerateIdentifier(string prefix, bool fipsCompliant, params string[] args) Lines 321-355. This method automatically defaults to MD5 since there is no input from heat.

Exception Type: System.InvalidOperationException

Stack Trace: at System.Security.Cryptography.MD5CryptoServiceProvider..ctor() at Microsoft.Tools.WindowsInstallerXml.Common.GenerateIdentifier(String prefix, Boolean fipsCompliant, String[] args) at Microsoft.Tools.WindowsInstallerXml.Extensions.DirectoryHarvester.HarvestDirectory(String path, String relativePath, Boolean harvestChildren) at Microsoft.Tools.WindowsInstallerXml.Extensions.DirectoryHarvester.Harvest(String argument) at Microsoft.Tools.WindowsInstallerXml.Harvester.Harvest(String argument) at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

Originally opened by bruce.brown

[wixbot]

Need a switch to maintain backward compatibility with MD5-generated ids.

Release changed from v3.8 to v3.x

[egret85]

This issue has been open for many years. Are there any plans to fix this issue? Other parts of WiX support the "-fips" flag correctly, Heat not supporting it is causing major issues for a project I am working on.

[robmen]

The issue is open and waiting for someone to take it on. It's been open for years because no one has show that interest.

[marksjon]

This feature is still needed!

[barnson]

Triage says we'd take a change for WiX v3, as long as it's opt-in, for backward compatibility.

[Herohtar]

I'll try to take a look at it soon and see if I can get something working.

[icpenguins]

@Herohtar I wanted to share my two cents on this. It has been a few years since we did this work originally (https://blogs.msdn.microsoft.com/icumove/2009/02/06/wix-now-runs-on-fips-enable-machines/). I don't remember for sure why we didn't create our own algorithm, but one late night at the WiX working group we decided to move to SHA1. This came after conversations with internal security teams about the uniqueness of a hash which is needed for this particular application to ensure repeatable, random Ids are generated. A concern I would have is that SHA1 might be removed from compliance in a new standard in a couple years as well.

In this use case, we don't care about the cryptography but rather the repeatable, random generation, it might be best to own the algorithm in WiX rather than using system cryptography. This is similar to the non-unique GUIDs we generate.

In my opinion, this could mean that there would be a new, third switch which states -stableIds or something like that. This would then leverage the internal algorithm for generating the hash value.

[robmen]

@icpenguins you're correct but cryptographically secure hashes are used for generated GUIDs because the GUID v3 (I think v3) spec specifically calls out SHA1. We're following those specs.

[icpenguins]

@robmen I believe we are saying the same thing. My suggestion is making that SHA1 or whatever, algorithm local. Since WiX doesn't need the cryptography to be unbreakable it might be worth owning the hashing algorithm to avoid this all together.

You are correct that it is v3. The below algorithm would also have problems if SHA1 becomes deprecated from a security perspective. I just don't think it is valid to need to keep passing in command line values at this point since the security of the hash doesn't concern us and didn't concern the security team.

https://github.com/wixtoolset/wix3/blob/bda1c281cb0349007d767d5404d6da87076d7d94/src/tools/wix/Uuid.cs#L22-L72

Again, my 2 cents.

[robmen]

AFAIK, the applicable specs for generating GUIDs rely on MD5 or SHA1. If you suggesting we should implement SHA1 (or MD5) by hand then... I'm not sure where we'd start. That sounds like quite an undertaking. 😅

[icpenguins]

@robmen They are both a spec...copy and paste would probably be the easiest! 😉

https://en.wikipedia.org/wiki/MD5
https://en.wikipedia.org/wiki/SHA-1

[Herohtar]

@icpenguins Maybe I don't understand what your point is, but from my understanding, the only reason there are flags to begin with is because you don't want to break compatibility with existing projects, so the compliant algorithms have to be opt-in. It makes sense then in wix3.x to keep the flags and SHA1 (whether it's the best choice or not) and just add the ones that were missed in the first pass so that people who need to use those features on a FIPS-enabled system at least are able to use it.

wix4 uses mostly SHA1 and doesn't have any flags, so what whatever custom algorithm you're wanting would probably be an idea to target at that version.

[icpenguins]

@Herohtar Yes, that is why there are flags. We need to keep the backwards compatibility. I am saying now, with hindsight being 20/20 and the MD5 and SHA1 hashes being specs, porting those algorithms to WiX fixes the issue permanently, no matter what happens in the crypto world in terms of security now or in the future.

In fact, as I look at the openness of the algorithms, you are correct, there is likely not a need to create a third switch which is custom. Porting the MD5 and SHA1 hash gets rid of the problem.

[Herohtar]

I see. I agree it would be nice to not have the potential of the algorithm being disabled.