search

wixtoolset / issues

WiX Toolset Issues Tracker
http://wixtoolset.org/
129 stars 36 forks source link

Investigate the use of human-readable strings to generate upgrade code #8584

Open barnson opened 4 months ago

barnson commented 4 months ago

User story

For some reason, not everyone loves GUIDs. WiX has spent many years fighting them. One remains: The upgrade code. What if we generated a stable GUID for a human-readable string?

Proposal

We generate stable component GUIDs using the right set of inputs based on type of keypath. We could do the same thing for upgrade code and provide guidance for creating a well-formed human-readable "upgrade id." Two ideas:

It's an arbitrary string, so we could have advanced guidance for, e.g., side-by-side scenarios.

Considerations

bevanweiss commented 2 months ago

I assume this would just be mapping the setup author string => MD5 hash or such (i.e. 128bit GUID equivalent) Given in MD5/GUID form there is nothing special about the original string anymore, does it need any guidance beyond "This string should be unique"?

It could perhaps be 'in-place' i.e. where the current Upgrade Id requires a GUID, maybe the 'enhanced version' could accept either:

jamescaldwell commented 2 months ago

I could take on this task. The logic I would use would be to allow the regular call to GetAttributeGuidValue prodeed under the UpgradeCode case. If it fails, then make a hash using md5 and then convert back to a string. This could be applied to every Guid parsing, or just to UpgradeCode.

barnson commented 2 months ago

If triage accepts this, it will need a WIP/design. For example, it can't use MD5 and I'd argue against overloading the existing UpgradeCode attribute.

barnson commented 2 months ago

Investigate whether other packaging technologies (e.g., Msix) have a concept of "product family" that we could use to come up with a name better than UpgradeId. @robmen is noodling on the concept of this idea as a "package identity" in more general terms. Assigning to him for the moment.

barnson commented 1 month ago

AUMIDs are another scheme: https://learn.microsoft.com/en-us/windows/win32/shell/appids

bevanweiss commented 1 month ago

If triage accepts this, it will need a WIP/design. For example, it can't use MD5 and I'd argue against overloading the existing UpgradeCode attribute.

I've just seen the last WiX online. What's the reason for the anti-MD5 in this context? It's the most standard 128bit hashing algorithm. And this is certainly not a cryptographic application, so the reversibility vulnerability isn't really a factor.

barnson commented 1 month ago

MD5 fails when FIPS is enabled.

bevanweiss commented 1 month ago

MD5 fails when FIPS is enabled.

Ahh, so it's not anti-MD5, just can't use the CLR Cryptography MD5 implementation in FIPS environments. And I guess when people deploy FIPS mode they push it to development machines as well... I wouldn't be surprised if that caused issues with Visual Studio usage also.. I guess VS has had the time to move away from MD5 for various hashing to GUID length things.

Does modern .NET Core still do similar?

.NET Core:

  • Passes cryptographic primitives calls through to the standard modules the underlying operating system provides.
  • Does not enforce the use of FIPS Approved algorithms or key sizes in .NET Core apps.

https://learn.microsoft.com/en-us/dotnet/standard/security/fips-compliance It looks like it does not. So it's only really about .NET FW versioning (which I guess is still a majority support target for the development environment as well).

xxHash128 has been something that I've used before for cache management. It looks like it's even so popular that it's made it's way into the .NET MS libraries https://learn.microsoft.com/en-us/dotnet/api/system.io.hashing.xxhash128

barnson commented 1 month ago

WiX has Uuid.NewUuid to handle GUID creation for components.