Updated python_packages osquery query

[ksykulev]

A new feature in osquery 5.16 was created to allow for scanning of user directories for python packages. If the new version of osquery is detected use the new query, otherwise use the old query.

#26423

• Changes file added for user-visible changes in changes/, orbit/changes/ or ee/fleetd-chrome/changes.
  See Changes files for more information.
• Added/updated automated tests
• A detailed QA plan exists on the associated ticket (if it isn't there, work with the product group's QA engineer to add it)
• Manual QA for all new/changed functionality

[ksykulev]

I tried to add some tests in server/service/osquery_utils/queries_test.go. However, because this method is called during var initialization, it is very hard to stub either fleet.OsqueryVersion or semver.NewVersion.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.84%. Comparing base (6e3d6dd) to head (72c5159).
Report is 51 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #26434      +/-   ##
==========================================
+ Coverage   63.72%   63.84%   +0.12%     
==========================================
  Files        1655     1659       +4     
  Lines      158995   159162     +167     
  Branches     4144     4144              
==========================================
+ Hits       101321   101619     +298     
+ Misses      49737    49602     -135     
- Partials     7937     7941       +4     

Flag	Coverage Δ
backend	64.67% <100.00%> (+0.13%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iansltx]

How does this work when a fleet of hosts have mixed osquery versions? This feels like we're hard-coding the query for the entirety of the Fleet server, which means this will either skip the new functionality or break old clients depending on when Fleet was built, rather than based on what the host actually has installed.

Feels like the right place to put this is in GetDetailQueries, potentially as another type of override. Splitting this query up might allow for more code reuse with that override.

Likely need to update gen_queries_doc.go as well to either split results based on osquery version, or at least link to GitHub history for how vitals queries change while mentioning which osquery version those queries correspond to.

The catch with this is that we'll have one query in detail queries relying on the result of ingesting another detail query, which is particularly tricky when setting things up on enrollment, but this looks fixable by splitting the detail queries onto a group that relies on host into and a group that doesn't, running the "doesn't" group first, then passing host info into the generator for the rest. Then if we don't get osquery info back we assume an old version of osquery, which will return less info but won't break.

Nice thing about all of the above is it makes this a lot more testable, since calling an endpoint with differing query results for osquery_info will kick back the relevant software query.