The meeting this week had much less drama to discuss, as various brouhahas have been resolved favorably. Instead, we got to do our typical bit of triage and design discussion, which felt refreshingly normal.
Issue triage
progress text issue, from @punkbuster2003, highlights that on Windows 11, progress messages in native MSI UI are showing up with their formatting characters intact, instead of being formatted as they are in prior versions of Windows. Unfortunately, that's all internal to MSI and WiX can't influence it. Microsoft has to fix it -- and this bug has happened before, in Windows 10, and was (relatively) quickly fixed; we hope the same will be true for Windows 11.
Visual Studio 2019 locks output file of a project's dependency while building installer via wix toolset, from @meTur4ik, appears to indicate that the
HeatDirectoryharvesting task locks files in a way that prevents a subsequent build in Visual Studio. We took the issue for investigation in WiX v4.0.Feature Request: include Wix Toolset installers in winget, pretty please!, from @CrapuleJack, requests that WiX be available via the
wingetWindows Package Manager. Rob volunteered to investigate whether the Votive Visual Studio extension could be installed viawinget.
Design discussion
Today we discussed an issue that came up earlier this year when Microsoft started replacing the .NET Framework redistributables with ones signed with new Authenticode certificates. Also, in a bit of a policy shift, they're also now updating the redistributables in-place with newer versions. That's a problem for Burn: It relies on the strong promise given by verifying the hash of files it downloads. When files are updated at the same URL, the hash changes and Burn rightly complains.
Sean opened an issue suggesting that Burn should be able to rely exclusively on Authenticode signature to verify downloads. That would let Microsoft update the .NET Framework redistributables with newer versions -- as long as the Authenticode signature didn't change. Verifying the Authenticode signature isn't as strong a guarantee as a hash that you're getting what you expected; it just verifies that the same entity signed the file. That's a safe bet for a Microsoft download -- probably -- but might be more concerning for other downloads. So I opened another issue to make it easier to self-host packages downloaded by your bundles.
Our discussion concluded that trusting the Authenticode signature is the best idea we can think of to still provide reasonable security. Rob and Sean are splitting the work to bring Authenticode-only verification back to Burn.