add force-build-new-FODs.sh maintainer script#313248
add force-build-new-FODs.sh maintainer script#313248risicle wants to merge 1 commit intoNixOS:masterfrom
Conversation
this can be used to check whether newly-introduced FODs in, for instance, a pull request, produce the purported output hash despite that output hash/path possibly already existing in a binary cache.
ofborg
bot
added
10.rebuild-darwin: 0
|
Thanks, I will try to give it a try when I've some time. Would be great to integrate it in nixpkgs review if ofborg is not going to run it automatically. But just wanted to drop a line saying that this is a nice to have and "easy" (compared to fixing nix directly) to implement mitigation, but a true fix would be to do it directly at nix's level as discussed in NixOS/nix#969 (comment) For instance, I guess that this script would be unable to detect this kind of attack targeting a different architecture than the one of the current user? |
mweinelt
added
the
1.severity: security
|
How long does it take to run this? usually doing a nixpkgs-wide eval is pretty ram and time intensive for me. |
|
😁 It takes just about as long as you suspect, which is why I was interested in piggy-backing on ofborg - it already does the required evals. There's actually no limit to how long it can take when e.g. a common fetcher's hash changes - it can technically want to build quite a few non-FOD derivations in order to be able to build the FOD derivations. But ofborg itself isn't immune to this sort of thing and usually people ignore crazy ofborg results for staging PRs and the like. It occurred to me the other day that this script would still have some value if it were simply run periodically against master. Might not catch things pre-merge, but it's better than the current situation. |
wegank
added
the
2.status: stale
nixpkgs-ci
bot
removed
the
2.status: stale
nixpkgs-ci
bot
added
the
12.approvals: 1
|
This was written quite a while ago, it's worth checking it still works. |
6 participants
Description of changes
See the later discussions in NixOS/nix#969, NixOS/ofborg#68, NixOS/rfcs#171 around concerns that the nixos binary cache could be "seeded" with a malicious source package in a quiet under-reviewed corner of nixpkgs which then gets re-used in a more security-critical place through a hash confusion attack.
The following script can be used as a mitigation to this, enabling reviewers to check whether new or changed Fixed-Output-Derivations actually produce the purported output hash when not pulled from a cache. It actually works by producing a "tainted" copy of any new FODs with a random hash and checking what "
got:" hash nix lists when the hashes fail to agree.There are obvious synergies here with what ofborg does - particularly the most computationally intensive part, performing the full nixpkgs evaluation. However it appears that the ofborg team don't have the capacity to act on this now, so it's probably better to get a standalone copy of this script in more peoples' hands.
The script in fact uses a modified version of ofborg's
outpaths.nix, along with a few other embedded sibling scripts. There are of course downsides with using embedded scripts, but I chose to go this way because it keeps the script very self-contained and means I don't have to solve problems like locating these other scripts at runtime.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.