Uploaded package doesn't map to existing software title

[noahtalerman]

Fleet version: Unknown but likely an issue in Fleet 4.50. We decided not to resolve this in 4.50

---

💥  Actual behavior

Roberto: This has happened with a couple of apps already. Note how the installer is "Microsoft Edge", but after I install it, I have a different software title named "Microsoft Edge.app", from a different source:

🧑‍💻  Steps to reproduce

1. Upload Microsoft Edge (.pkg) to Fleet
2. Install Microsoft Edge on a host

🕯️ More info (optional)

Discussion from Slack here (internal)

Noah: Is this a door we can’t walk back out of? Put differently, if we ship as-is and a user uploads Edge, will we be able to “squish” the two software titles into one title for them in a later release? If yes, I think we can ship as-is and file a bug so we can make a quick follow up to improve the matching.

Roberto: The matching is done in two places:

1. when the user uploads the installer, we try to match installer metadata -> existing title, If we don't find any, we create a new one
2. in a cron job, after getting host software via osquery we try to match incoming host software -> existing title. for software that was already uploaded, we can't do 1 easily anymore, so if that's what we need to tweak it'll be a bit challenging

Noah: Got it. So, if we were to ship as-is w/ a bug fix later, then we’d probably do two things:

• Improve the matching
• Add another cron to match uploaded software that isn't matched

Odds are we don’t get the matching perfectly even if we plugged all the gaps this release right?

So, even if we plugged all the gaps we know of now, I’m thinking it’s likely we’ll add something like that new cron to match uploaded software later.

🛠️ To fix

Improve version > title matching for macOS apps.

• Create software titles for macOS apps based on bundle_identifier instead of the name
• When PKG is uploaded and there's no existing title that match bundle_identifier extracted from package -> create new title one
  • Use name extracted form distribution.plist file to create title
  • In case name don't match name of the app once installed (osquery reported) > merge two titles
  • Osquery reported title should be swallowed into the newly created title (because if we do other way around, it might break automation for API users that used software_title_id of the newly created title
    • ex: If a user uploads zoomInstaller.pkg and we extract name Zoom Workplace and bundle ID us.zoom.osx. After app is installed osquery will report version named Zoom.us.app and we'll have two separate titles for same app. In this case osquery reported title Zoom.us.app will be merged into Zoom Workplace (title ID will be kept) and name from the osquery title will be infered.
• Add bundle_identifier field to software title details

Improve name, bundle_identifier extraction. For name extraction get information in the following order of priority:

1. bundle-version[0].bundle[0].path (extract from first <bundle-version> -> <bundle> -> path attribute)
2. title
3. product.id
4. pkg-ref[0].id

For bundle ID extraction get information in the following order of priority:

1. must-close[0].app[0].id extract from first <must-close> -> <app> -> id attribute)
2. product.id
3. pkg-ref[0].id

[marko-lisica]

Hey @roperzh, we decided to work on software title matching separately from VPP story. Can you take a look at "To fix" section of issue description.

It's mostly what we discussed yesterday during our call, with one change. Instead of merging title that's created via upload to osquery reported title, we would like to do reverse (merge osquery title to one that we created). What do you think about this approach?

Also, I spent some time and dug into many distribution.plist files for different apps, so I would like to update the extraction logic.

I found out that some apps have must-close element and bundle ID is always correct there. (e.g. in Zoom's package only correct bundle ID is inside the must-close element, that's why I would check that first and if not available, then go to the next one). Also, I found out that many packages have bundle element inside bundle-version element which has path attribute, which is usually <app_name>.app which I would use before the <title> element.

[marko-lisica]

@roperzh btw I used the format bundle-version[0].bundle[0].path which might not be correct but added an explanation of what should we read in parentheses.

[roperzh]

@marko-lisica sorry for the delay on this

It's mostly what we discussed yesterday during our call, with one change. Instead of merging title that's created via upload to osquery reported title, we would like to do reverse (merge osquery title to one that we created). What do you think about this approach?

this makes sense, we should reach out to you ASAP if we find any gotchas during the actual implementation, but I can't think of anything right now.

I found out that some apps have must-close element and bundle ID is always correct there. (e.g. in Zoom's package only correct bundle ID is inside the must-close element, that's why I would check that first and if not available, then go to the next one). Also, I found out that many packages have bundle element inside bundle-version element which has path attribute, which is usually .app which I would use before the