After a weekend recovering from another heroic effort to keep WiX users safe, we're back to discuss what's in those releases and what's coming up in our next release, less than two weeks away. Join us for an earlier-than-fortnightly meeting next Tuesday, 2-April, for a final checkin before the scheduled release of WiX v5 on Friday, 5-April. And in the meantime, read on to see what we've been up to.

Security releases

Now everybody knows why we've been so busy (cranky) lately: We had reports of two security vulnerabilities that affected three versions of WiX. We released WiX v3.14.1, WiX v4.0.5, and WiX v5.0.0-rc.2 last Friday, 22-March. Please upgrade -- the Burn vulnerability requires that a user is already infected with running malware but it's still a privilege escalation, which in the security field is commonly called "bad."

WiX v5 release plan

WiX v5.0.0-rc.2 was released on 22-Mar-2024, along with our other security releases. It contains those fixes as well as a couple of fixes for bugs reported after -rc.1. The incoming rate of v5-specific bugs has been low, so we're feeling fairly confident in our schedule:

  • v5.0.0-rc.1 on 8-Mar-2024 (done!)
  • v5.0.0-rc.2 on 22-Mar-2024 (done!)
  • v5.0.0 on 5-Apr-2024

Our analog AI project management tool is similarly confident about shipping as scheduled: "Signs point to yes."

Issue triage

  • Discrepancy between WixVariable documentation and behavior, from @avivanoff, points out that the documentation makes a stronger statement than the compiler. Who's right? Well, according to the concepts of documentation-driven development, we should trust the documentation, but we know that sometimes, code changes aren't reflected in the documentation, so I took this bug to fix the documentation.

  • FirewallException (v5) Profile regression, from @dorssel, was a WiX v5.0.0-rc.1 bug that revealed itself when running ICE validation. I fixed the bug and ensured validation runs during these tests, not that we're going to run into this kind of bug again...

  • Auto-MajorUpgrade with overridable RemoveExistingProducts scheduling, from @dorssel, requests the ability to reschedule RemoveExistingProducts when using the new magic major upgrade feature in WiX v5. Though this would require three lines of XML versus a non-magical one-liner MajorUpgrade element, we agreed that it's consistent with other symbols that WiX automatically supplies. I volunteered to implement this mini-feature.

  • msi decompile -x deletes everything on the selected folder, from @Signum21, points out that when you extract files when decompiling an MSI package, WiX brazenly deletes the specified target directory. It turns out that you might not have been expecting mass deletion. This issue is open up for grabs.

  • A PendingFileRenameOperations entry is present after Burn exit., from @DS-AndOrz, reports that some bundles, at least, are leaving behind temporary files that Burn is then using the "move file to the temp directory" trick that lets you appear, at least, to have deleted an in-use file. Burn then politely asks Windows to clean up such files at the next reboot when they will no longer be in use. Though the machine isn't in a pristine state, technically the reboot is just for cleaning up files that Burn was trying to delete, so it isn't strictly required. Still, it would be good to track down the offending file to see if it's something Burn could clean up some other way, so this issue is open up for grabs.

  • ColumnCategory.Unknown shouldn't mean null, from @barnson, came up when I was trying to figure out how to not set a column's category in a custom table. I eventually figured it out -- in a bit of quirky behavior, you use Unknown to indicate a null category, instead of something less quirky, like Null. Well, I'm a fan of quirky, so I didn't volunteer and instead let this issue go up for grabs.

  • IniFile removeLine doesn't create an entry with Action=2 into RemoveIniFile table, from @phenaste, reports some bad data getting into an MSI package when using some of the IniFile/@Action values. It turns out some names that shouldn't have been in alphabetical order were, in fact, alphabetized. I added some chaos back into the system and fixed this issue in WiX v5.

  • WiX 3.11.2 -> 3.14 breaks NetFx PackageGroup References, from @chrpai, reports that some of the package groups that were present in WiX v3.11 are missing in WiX v3.14. Indeed they are -- that came about almost two years ago, when Microsoft broke all their redistributables by replacing some of them with newer packages signed with SHA-2 signatures. Redistributables that weren't replaced were out of support so as part of the effort to "fix" WiX, we removed the obsolete packages.

  • Installation with scope "PerUser" fails when package NetFx462Redist is used, from @dotriz, is a bug due to a change in Burn's caching behavior between WiX v3 and WiX v4. In WiX v3, a per-user bundle could contain a per-machine package (like a .NET redistributable) and if it didn't need to be installed, it wouldn't be cached and elevated privileges weren't required. Now, the default behavior is to cache it (bug #1), which requires elevated privileges, but Burn doesn't prompt the user to elevate (bug #2). The workaround is to use a custom package group with the ExePackage marked Cache="remove", which prevents the caching attempt if the package is already present on the machine. I took the issue to investigate one or both bugs in WiX v6.

  • WiX 3.14 introduces ICE103 validation error, from @chrpai, is an example of some of the troubles we've had with ICE validation over the years. The ICEs (internal consistency evaluators) come from Microsoft with varying quality. Rob fixed this issue by going to a prior release of the ICEs that behave better but don't support Arm64. It's not at all perfect but provides better behavior overall, given the relative rarity of Arm64 merge modules.

  • bal:Condition hangs bundle when bal:WixInternalUIBootstrapperApplication is used, from @uralm1, reports that using the Condition element in a bundle whose bootstrapper application is WixInternalUIBootstrapperApplication results in a hang. It's not clear if it's supposed to work in WixInternalUIBootstrapperApplication; there is code there to handle the message but WixInternalUIBootstrapperApplication doesn't have any of its own UI so this might be a feature intended only for WixStandardBootstrapperApplication. This issue is open up for grabs for someone to investigate the intent and to figure out how to implement it.

  • MSI Decompile results in trimmed source paths for File, from @nterhorst-eagerit, suggests that when decompiling an MSI package and extracting its files, the decompiler should use the authored file names. Instead, the decompiler uses the file ids as the names for the extracted files, because they're guaranteed to be unique. Decompilation doesn't create a directory tree; if that's what you want, you can get that from Windows Installer itself with an admin installation.