fleet
fleet copied to clipboard
Windows Chrome FMAs don't have hashes specified in manifests
💥 Actual behavior
WinGet based Chrome FMAs refer to a non-versioned download URL, so the latest version of Chrome gets downloaded rather than the version specified in the manifest we pulled. This means that the hash of the installer won't match if we don't immediately detect and merge an update to the installer in our own manifests, if we specify a hash. #27755 avoids this by dropping hash checking there as well, but this means that we don't verify that the installer downloaded matches the one we expected.
🧑💻 Steps to reproduce
- Point to a non-current Chrome Windows FMA manifest with a hash specified (anything at or earlier than April 1 ~3pm CDT).
- Attempt to add the Chrome Windows FMA.
🛠️ To fix
EXE versions of Chrome are available that include version in the URL. Tradeoff is those EXEs will need a custom install script, and may not include an UpgradeCode for building a version-agnostic uninstall script.
Need to decide on a desired fix here. Only thing I'm sure about on my estimate is doing this for Windows, and I'm adding padding for macOS.
Hey team! Please add your planning poker estimate with Zenhub @jahzielv @ksykulev
Per discussion yesterday, split off the macOS work; this is now a Windows-only ticket, and was already estimated as such.
QA Notes
- [x] Chrome can be added to library as FMA
- [x] Chrome is added as .exe file, version 138.0.7204.158
- [x] Chrome installs successfully on Windows host
- [x] Chrome launches successfully
- [x] Chrome uninstalls successfully on host
- [x] Activity items are created
Chrome's version dance, Hashes match in cloud's glass stance, Trust in each advance.