For “security & audit purposes” I’m required to submit a list of packages through an MDM solution which uses osquery so I’m going to try to take a shot at implementing nix_packages virtual table.
For the intents of this endeavor I assume that “package” is a derivation which comes from nixpkgs or other “repository” (including flakes) and its output(s) is something akin to a traditional “package” (deb, rpm, etc.) as this is how other virtual package tables work in osquery.
However, it is far from trivial to identify which derivations result in actual packages.
I’ve tried multiple approaches and I achieved what seems like the best results with
nix-store --query --requisites <gc-roots...>sqlite3 -readonly /nix/var/nix/db/db.sqlite "select distinct deriver from ValidPaths;"
The nix-store one includes quite a lot of non-packages (confs, *sh_completions, dangling sources, systemd units, scripts, etc.)
The nix db one seems to include drvs which mostly seem to be the recipes for what I consider a “package”. It contains less “non-packages” than the nix-store approach.
however, it contains a lot of drv paths which do not exist in /nix/store which can trigger a lot of false positives.
Because of this, additional test are required.
Currently I still prefer the nix db approach as the drvs contain enough metadata to reasonably assume whether they refer to a “package” or a “non-package” but I’m worried about the nonexistent paths and also whether the list is in fact exhaustive.
“Reasonable assumption” above means the derivation contains env.pname and/or env.version but I’m not sure this can be relied upon 100 %.
I couldn’t find a better approach tho.
Is there a “good-enough” solution? It’s better to have a few false positives than any false negatives.
