Apply software version transformations to uploaded custom packages

[iansltx]

Problem

Currently version number transformations for proper vulnerability matching only happen on software ingestion from osquery. If an installer is uploaded with a similar version issue, we don't touch the version number.

This matters for upcoming (Q1'25 software OKR) patching workflows, as we'll likely need to tweak automated query generation for "does this host need to be patched" for known cases where the installer version won't match what we would see in osquery (if we base patching workflows on policies) or in software inventory (if we base patching workflows on software inventory post-ingest).

What have you tried?

There is currently no way (other than modifying in the DB) to tweak the version number of a custom package once it's been uploaded to Fleet. Modifying the package could be a workaround, at the expense of any code signing the package has.

Potential solutions

Add a templated (hard-coded first, to be replaced later with a feed that is pulled independent of Fleet release cycles) way to modify software title versions on upload before they hit the database. Note that this will likely be a different set of transformations than we have for software ingest.

What is the expected workflow as a result of your proposal?

If I upload an e.g. Python for Windows installer, and then ran that installer on a host, the version reported from the host for patching purposes should match the version associated with the installer.

For reference, right now the installed version of Python for Windows would report as newer than the installer version (installer has dot-zero where installed has a 1xxx static number representing Python ABI). Once #24611 lands to fix vulnerability processing mismatches, the version reported in software inventory will be lower than the version extracted from the installer (e.g. 3.9.1150.0 for the installer vs. 3.9.1 for software inventory).