Custom package app mismatch: Windows App identified as Microsoft AutoUpdate

[allenhouchins]

Fleet version: Latest on dogfood

Web browser and operating system: Any

---

💥  Actual behavior

If you upload Windows App (yes, that's the name... it's their replacement for Remote Desktop), we identify it as Microsoft AutoUpdate.

🧑‍💻  Steps to reproduce

1. Download Windows App: https://go.microsoft.com/fwlink/?linkid=868963
2. Upload as a custom package
3. Notice its labeled as Microsoft AutoUpdate and the "Show details" points to Microsoft AutoUpdate in /Library/Application Support/ instead of the Windows App app deployed to /Applications

🕯️ More info (optional)

🛠️ To fix

Product designer: @marko-lisica

Fix this such that Windows App reports the correct name and bundle ID, while not breaking any other package metadata extraction. We may be able to do this by deprioritizing MS AutoUpdate in cases where multiple items are in the same package and MS AutoUpdate is one of those items.

[jmwatts]

@allenhouchins @noahtalerman
I'm pretty sure this is the same issue described here: #19826 (comment)

If the .pkg has multiple parts, it grabs the name of the first one it comes across. If you expand the Windows app pkg using

pkgutil --expand /Users/janis/Downloads/Windows_App_11.1.9_installer.pkg /tmp/windows_installer

You can see that AutoUpdate is one of the packages inside it:

So this ticket and #19826 should either be consolidated or tracked together.

[noahtalerman]

Thanks for digging into this Janis!

@mostlikelee is there a fix we can make for just "Windows App" to move quickly based on what we learned from prospect-fountain?

cc @marko-lisica

[iansltx]

Quickest (in terms of when it gets into the hands of customers) workaround would be adding Windows App as a Fleet-maintained app, as it's available in Homebrew.

We already made some tweaks to get this right on MS Company Portal, which had the same issue. We can make further tweaks to get something working here that doesn't break anything else, but if we want to do this explicitly as a one-off (e.g. mentioning Windows App by name/bundle ID) the Fleet-maintained app approach would be the better way to handle that.

[iansltx]

FWIW I was just in the relevant code (xar.go) for work that will ship in 4.72 (which unfortunately doesn't fix this particular issue), so I don't mind planning on taking that work.