As you might have heard, the xz package has a backdoor that seems to have been installed by the developer https://www.openwall.com/lists/oss-security/2024/03/29/4 . You should check the version you're running and downgrade if possible.
On most systems, it would be pretty hard to figure out which programs on your system run which version of xz. Nix, however, has some cool commands for figuring this out.
The main thing we want is to find all store paths (built programs) which have this package as a dependency, which you can do with nix-store --query --referrers $(which xz)
This prints out the store paths of which xz is a direct dependency. If you want the entire graph of dependencies (i.e. the entire blast radius of a dependency), run
nix-store --query --referrers-closure $(which xz)
This is one advantage of having a central place to store builds and their build specs (derivations). Imagine you're a big company, and an SSH vuln is made public. How do you check which of your running systems is affected? still just those commands above.
voila. practice safe package management anon.
reply
You can also explore the tree of your system's derivations with nix-tree https://github.com/utdemir/nix-tree
For example, run nix-tree /nix/var/nix/profiles/system search for the package name with / and then explore the parents and descendants of that package...
reply
To me, this is a strike against nix. I don’t care for nix, but the ability audit the exact global version of link depends should not require esoteric package queries. Does this surface in standard instance management software?
reply
how would you do this in other systems? this isn't about auditing the version, but the dependency graph where the package occurs. afaik this isn't possible in other linux systems without even more complex queries.
reply
Osquery generally, but this doesn’t grab the package list in nixos (open GitHub issue: https://github.com/osquery/osquery/issues/8179)
reply
Much Appreciated
reply