WoT verify pinned nixpkgs #78
Conversation
There was a problem hiding this comment.
Thanks for writing this up and verifying the maintainers. This is actually quite cool!
A few considerations:
- What if we desparately need a fix that's not yet buried in a signed commit?
- What if we miss an important fix by accident during the regular update because it's not yet buried in a signed commit?
- Before we merge this we need a script that does everything automatically because it's quite boring to search for a signed commit from the list. Perhaps this whole PR can be a script so we don't have gpg keys in both a markdown file and a script which makes maintainability harder? Ideally the script would recv the keys, clone both nixos-unstable and nixos-19.03 into a temporary dir and then produce a nixpkgs-pinned.nix file.
|
|
||
| Procedure | ||
| --- | ||
| 1. Search for most recent signed commit on [nixos-19.03](https://github.com/NixOS/nixpkgs-channels/commits/nixos-19.03) or [nixos-unstable](https://github.com/NixOS/nixpkgs-channels/commits/nixos-unstable) |
We can always manually add a commit hash to nixpkgs-pinned.nix in emergencies. The standard could reflect this. In that case we would just not use the script and revert to manually updating.
Quite a few of the recent commits in https://github.com/NixOS/nixpkgs-channels/commits/nixos-19.03 and https://github.com/NixOS/nixpkgs-channels/commits/nixos-unstable are properly signed according to our specifications, which should include all the previously buried updates. The script could introduce a time limit on how recent the commit must be, and throw an error if the latest properly signed commit is too old.
Yes, will do. What do you think about this script getting the fingerprints from a list of manually verified maintainer key fingerprints signed by one of our keys? This could be a way to cryptographically certify keys with information from different sources, like Keybase, websites, and GPG WoT. Or would there be a more elegant way to verify fingerprints from Keybase proofs, WoT, and websites in a scripted way? |
46edb39 Add content hashes for pinned channels (Erik Arvstedt) 961e821 Rename contrib/ to helper/ (Erik Arvstedt) Pull request description: Unhashed external content is bad for security and performance (due to re-fetches when the cache times out). Use this simple fix until #78 is fleshed out. For testing, run this in the repo root dir: ```bash nix eval '(import ./pkgs/nixpkgs-pinned.nix)' ``` ACKs for top commit: jonasnick: ACK 46edb39 Tree-SHA512: cb098a4714aecf00e8d0f9fe6d388b6322416c1d2f8d55b54dc16328145331a87a71fbf68e2faa85105727cbd6370542799f1c2d84ac2bee90a6710b96eba9bd
|
Interesting approach, but I don't seem to exactly understand the threat model. Ok, supply chain attacks in a sense that somebody puts a backdoored bitcoind in nixpkgs. But why should a "commit-chain" that was extended by one of the trusted maintainers be better? A backdoor could be well hidden and the people could work on a completely unrelated features. What I want to say, if there is a backdoor you are screwed one way or the other. There should be a quorum of nix-bitcoin maintainers saying ok this stuff from nixpkgs seems sane. |
|
Threat model: GitHub slips a malicious update into the tree, attacker gets write access to the git repo and merges backdoored code without review At least when a trusted maintainer has signed the top commit we know that the state exists locally somewhere with somebody who probably looks at the changes to his nixpkgs very carefully. I suggest I implement this first and when we have more development resources we set up a quorum to review relevant nixpkgs. |
|
#162 is the PR to be merged |
This PR sets up criteria and procedure for verifying pinned nixpkgs and nixpkgs-unstable commits. Additionally it provides a list of nixpkgs maintainer keys that fully or partially meet the criteria. The standards described could be automated in a script for easy verification.
It is worth discussing how much security this additional effort actually provides.
Closes #75