JoStableford
commented
3 months ago Open ddribeiro opened 3 months ago
JoStableford
commented
3 months ago 
noahtalerman
commented
3 months ago If metadata is present, Fleet would pre-populate the text fields with the values and allow the admin to edit them, if they desire.
@ddribeiro thanks for tracking the desired workflow! What happens after the admin edits the field? Does Fleet do anything else with that metadata information? Or is it just displayed and the admin can edit it again? (like a notes field)
An example of a software installer with inconsistent or missing metadata is Cloudflare WARP
The application name has the version appended to the end. Version is not populated.
Not having a state for en empty empty feels like a bug to me. @marko-lisica if I'm remembering correctly, we don't have a state for this when we drafted the "Deploy security agents" story (#14921)
If that's right, when you get the chance, can you please file a bug for this? Should be a quick fix to add.
marko-lisica
commented
3 months ago Hey @noahtalerman & @ddribeiro, this should be solved when we release #19144
Looking at metadata in Cloudflare WARP it will return:
name: Cloudflare WARP.appversion: 2024.6.416.0bundle_identifier: com.cloudflare.1dot1dot1dot1.macosSoftware titles for macOS will be merged based on bundle_identifier, which means if there's Cloudflare WARP on any other host already installed, it will show up under the same title when a job that merges titles run (AFAIK every hour)
marko-lisica
commented
3 months ago Not having a state for en empty empty feels like a bug to me. @marko-lisica if I'm remembering correctly, we don't have a state for this when we drafted the "Deploy security agents" story (https://github.com/fleetdm/fleet/issues/14921)
We didn't spec since we didn't expect that it could happen that we can't parse version at all
noahtalerman
commented
3 months ago we didn't expect that it could happen that we can't parse version at all
@marko-lisica got it. I'm thinking it's still a possibility though and one that we should design for. Similar to error states / loading states in the UI. I think let's bring it through as a bug. Should be a quick frontend fix.
@roperzh please let me know if I'm wrong.
Problem
Fleet currently parses metadata associated with software installers after they've been uploaded. This is how we're able to display application name and version for that installer.
However, not all installers are created equal and sometimes this metadata is missing or incorrect. When this happens, Fleet is unable to group different version of the same installers or displays application names that are inconsistent with naming conventions chosen by an organization.
What have you tried?
An example of a good software installer with accurate metadata is Google Chrome for Enterprise. When uploaded to Fleet, the application name is consistent across versions and the version is populated in our UI:
An example of a software installer with inconsistent or missing metadata is Cloudflare WARP
The application name has the version appended to the end. Version is not populated. Version history likely will not work because I assume Fleet would consider each installer a unique application due to the name including the version.
Potential solutions
I think a good solution to this problem would be to display the detected metadata in an editable form in the Fleet UI immediately after a package is uploaded.
What is the expected workflow as a result of your proposal?
If metadata is present, Fleet would pre-populate the text fields with the values and allow the admin to edit them, if they desire. If the metadata is missing, Fleet would display a blank text field where the admin can add it themselves.
Software installer libraries can get unruly over time as the collection of installers grows. Capturing accurate installer metadata would allow admins to accurately manage their installers and remove old ones when they are no longer needed.