Name not extracting correctly from Google Chrome package

[pacamaster]

Fleet version: Fleet 4.54.1 Web browser and operating system: current browser and OS

---

💥  Actual behavior

When uploading Chrome Enterprise Google Chrome.app Fleet is taken as Chrome.app

🧑‍💻  Steps to reproduce

1. Upload Chrome enterprise package
2. notice App object in fleet is listed as "Chrome.app" and not the correct "Google Chrome.app"

🕯️ More info (optional)

https://github.com/fleetdm/fleet/blob/d73070406af26ee1c18a7322846f2711616b8a11/pkg/file/xar.go#L240-L254 - Looks to be where the name data is taken from, but unable to have different packages. One for regular Chrome and for Enterprise.

[JoStableford]

Related to a Slack conversation

[sharon-fdm]

Hey team! Please add your planning poker estimate with Zenhub @getvictor @iansltx @lucasmrod @mostlikelee

[iansltx]

I just picked the latest (128.x) archive apart and it shows "Google Chrome.app" there. Going to see if I can grab the older version to see if Google released a bugged archive.

[marko-lisica]

@iansltx I just tried it and it works well on dogfood (version 4.55.1). We had this issue before and solved it in #19144. Maybe this software was uploaded prior to this solution. If so, then we don't do migration for this.

[iansltx]

@marko-lisica to confirm, you tried with 126.0.6478.183? If not, I'll see if I can check with that package file locally. Guessing the answer here is either "we fixed it" or "Google did a weird thing for this particular version and we probably don't care to fix it" but I want to figure out which if we can find that package file (which is no longer accessible on Google's site from what I can find).

[iansltx]

Thx @Patagonia121 for the package file! Seeing if I can repro locally with that package on main. If not, I think we can close this.

[marko-lisica]

@marko-lisica to confirm, you tried with 126.0.6478.183? If not, I'll see if I can check with that package file locally. Guessing the answer here is either "we fixed it" or "Google did a weird thing for this particular version and we probably don't care to fix it" but I want to figure out which if we can find that package file (which is no longer accessible on Google's site from what I can find).

@iansltx I tested with the latest version 128.0.6613.114. I don't know where to find .pkg for 126.0.6478.183.

I had previously downloaded 126.0.6478.127, so I tried it and it worked.

[iansltx]

@marko-lisica Thanks for the clarification!

I'll test with 126.0.6478.183 now that I have the package for that. Good excuse for me to have my env set up for e.g. #20404 anyway.

[iansltx]

Was unable to repro locally with 126.0.6478.183.

Adding the reproduce tag back here. @Patagonia121 can you check with the customer on whether this is still a relevant issue? Based on the Slack convo this was observed after what we believe to be the fix was applied, so I'm reluctant to just close this out.

@marko-lisica you mentioned migrations; I'm guessing we don't want to modify app names in a migration to avoid packages moving out from under people, so lack of a name migration here would be intended behavior. Does that sound right?

[marko-lisica]

@marko-lisica you mentioned migrations; I'm guessing we don't want to modify app names in a migration to avoid packages moving out from under people, so lack of a name migration here would be intended behavior. Does that sound right?

@iansltx That right. We improved metadata extraction in #19144. If the user uploaded a package before we fixed it in version 4.54.0 it might have a incorrect name. The way to solve this is to remove the package and upload it again in newer version (above 4.54.0).

[iansltx]

With that in mind, do we want to

1. close this out, or
2. reach back out to the customer to confirm that we're repro'ing this the right way?

[sharon-fdm]

@lukeheath, any news on this ticket? Close?

[lukeheath]

@sharon-fdm I won't have time to follow up on this so I'm assigning to you. Will you please work with @zayhanlon to confirm we're reproducing this properly? Up to you how to proceed from there.

[zayhanlon]

@Patagonia121 is checking with the customer

[sharon-fdm]

Thanks @zayhanlon. It looks like this was solved. We typically wait a week for customer answers and close if we do not receive any.

[Patagonia121]

@zayhanlon @sharon-fdm the customer says this is still parsing the app name incorrectly on 4.55.1 - they're uploading the unmodified .pkg from https://chromeenterprise.google/download/.

[mostlikelee]

I've successfully replicated the issue, let me know if this a plausible scenario:

1. Manually install Google Chrome on a macOS host
2. On the host, rename Google Chrome.app to Chrome.app
3. Refetch the host
4. Run vulnerability scan cron (may not be needed, but doing this to ensure software titles are populated)
5. Upload GoogleChrome.pkg to the Fleet UI

The uploaded Google Chrome software is now associated with the existing Google.app software title.

[zayhanlon]

@mostlikelee is this a request for the customer ^ ?

[sharon-fdm]

Since it's reproduced, I moved to the ready column to be picked when possible.

[JoStableford]

Linked to Unthread ticket:

Conversation #2870)

[noahtalerman]

Hey @zayhanlon and @Patagonia121 I think we can close this issue. If customer-reedtimmer runs into it again, I think let's open a fresh bug.

• We made improvements to matching packages to software titles (see comment here).
• We confirmed the improvements work (see comment here: https://github.com/fleetdm/fleet/issues/20804#issuecomment-2322105015)). I just confirmed the fix again in dogfood.
• Tim reproduced this bug by manually renaming (see comment here) the app on his Mac. Looking at the original bug report, it doesn't sound like customer-reedtimmer is doing this:

cc @mostlikelee @sharon-fdm

[fleet-release]

Chrome name extracted, Fleet refines its keen insight, Clarity takes flight.