I’m an academic researcher (and Nix enthusiast!) interested in software repository security – specifically, how to protect users from compromised repositories (as opposed to bad packages served legitimately). The rough “best practice” in this space is The Update Framework (TUF). I think the reproducibility of Nix, plus a secure repository, will lead to the best software supply chain we have.
I’m interested in two things: a general discussion about the impact of repository security in Nix, and understanding the nixpkgs use case a little better.
Software repositories are a huge target. In particular, when using NixOS out-of-the-box, you’re trusting at least:
- GitHub (or wherever you’re getting nixpkgs from)
- Everyone with commit access to nixpkgs (to catch issues and to not be malicious)
There’s a bunch of ways this can go wrong, from outright malware (bad packages), to deliberately serving old/incompatible package versions.
TUF is an approach to repository security that aims to (1) minimize the damage any one party can do, and (2) allow recovery after a compromise. The main idea is to run your own little PKI (with offline root keys) and to assign different “roles”: each package has an owner that must sign it, someone’s responsible for compiling a consistent/coherent manifest of packages, and someone attests that the current manifest is up-to-date. (Each of these can require some threshold of several users).
I’m not necessarily advocating wholesale adoption of TUF in nix/nixpkgs, but I wonder if there are aspects we can adopt.
(I also haven’t totally digested the current security practices, so my understanding may be incomplete.)
As part of a current project (early stages; will be happy to share details as the work matures) I’m interested in the specific usage patterns of various software repositories. That is:
- how often do users
- how often do users download packages?
- how often are packages updated?
- how big are packages?
Is there anyone I might be able to chat about some of these with? (I could share details of our project.) High-level details would help us build solutions that work well at the scale of nixpkgs.