Hello! Here are some (somewhat unstructured!) thoughts about what it means to deliver secure updates to Guix users, and how The Update Framework (TUF) and related ideas can help us. To summarize, the problem we’re trying to solve is the “secure” update of Git checkouts. That’s because Guix is a set of recipes and code that is delivered to users/developers using Git. More specifically, we share most of the security goals listed in Sections 1.5.2 and 1.5.3 of the TUF spec¹. TUF is biased towards repositories of binary packages and associated meta-data, whereas we’re (1) using Git, and (2) concerned with source code authentication. Thus, some of the goals in 1.5.2 are not applicable, as we will see, and some of the roles in 2.1 are not applicable either. The OPAM folks came up with a variant of TUF² that takes advantage of the fact that the OPAM package repository is in a Git repo³ (this design is not currently used by opam-repository, AFAICS). Their scheme uses detached signature files for package meta-data instead of signed commits; thus, it is not concerned with Git checkout authentication in general, but with the authentication of individual files in the repo (see the discussion of “target files” below). Yet, there are good ideas applicable to our Git repo, such as the ‘signed’ tag created by a “signature bot” and that clients can use to check whether they get the latest version of opam-repository. The Qubes folks have their own process⁴, not inspired by TUF. They push signed Git tags (instead of signing commits), with roughly one signed tag every time a bunch of commits is pushed⁵. AIUI, Qubes uses the OpenPGP web of trust to determine which keys are authorized keys: a key signed by the Qubes master key is considered authorized. IMO this is a misuse of OpenPGP, where a signature on a key is a statement of trust in (certification of) the key/email and possibly key/name bindings⁶, and has nothing to do with authorization. At the very least, it’s clear that: 1. Guix clients, whether ‘guix pull’ or ‘git pull’, must be able to authenticate the history of their checkout; this is why we started signing commits. 2. We must use a mechanism such as the ‘signed’ Git tag described in the OPAM document so that clients can know what the latest Guix commit is. 3. We must follow the key management practices developed in TUF. Let’s go back to the “goals for specific attacks to protect against” in Section 1.5.2 of the TUF spec, and see how they apply to the distribution of Guix’s source tree: 1. “Rollback attacks. Attackers should not be able to trick clients into installing software that is older than that which the client previously knew to be available.” As explained in the OPAM document, Git gives us linearity guarantees (‘git pull’ makes sure we move forward), so clients can be sure they move forward in Guix history. We expect clients to authenticate the Git history, making sure all the commits are signed by authorized Guix committers. To perform such an attack, an attacker would need to get access to the private key of one of the authorized committers. We can probably consider it beyond the scope of our threat model, because at this point, the attacker could do anything (like the 2nd paragraph of TUF Section 2.2 suggests) and the version string of packages is really a detail. 2. “Indefinite freeze attacks. Attackers should not be able to respond to client requests with the same, outdated metadata without the client being aware of the problem.” 3. “Endless data attacks” and “Slow retrieval attacks” seem to be beyond the scope of our interests here; TUF does not seem to address them either. 4. “Extraneous dependencies attacks. Attackers should not be able to cause clients to download or install software dependencies that are not the intended dependencies.” Not applicable: we’re distributing a Git source tree, not build artifacts. 5. “Mix-and-match attacks. Attackers should not be able to trick clients into using a combination of metadata that never existed together on the repository at the same time.” Not applicable, for the same reaons. 6. “Malicious repository mirrors should not be able to prevent updates from good mirrors.” Clients should check the age of the ‘signed’ tag, and thus detect outdated mirrors. Section 2 of the TUF spec defines the notion of “target files” and discusses roles and the PKI. “Target files” are defined as files distributed by the system as commonly found in “traditional” package repos (e.g., binary packages and associated meta-data); they are the unit of authenticable data. In Guix we want to authenticate whole checkouts, so the notion of “target file” seems to make little sense. For instance, it wouldn’t make sense to sign each gnu/packages/*.scm file individually, because the meaning of these files depends not only on the surrounding files, but also on the core of Guix, such as the (guix packages) module, which defines the very notion of “package”. The PKI and roles described in TUF, with separate responsibilities and the ability to delegate, make a lot of sense (it’s similar in spirit to SPKI⁷, but more limited in scope.) Some of the roles do not seem to be applicable to secure Git update delivery: • the “targets” role is not applicable, at least not to individual source files; • the “snapshot” role does not seem applicable (a Git commit *is* a complete snapshot); the “timestamp” role, though, corresponds to the signature bot described in the OPAM document; • the optional “mirrors” role doesn’t seem very useful, as acknowledged by Section 2.1.5 of the TUF spec. With that in mind, we now need to see how to map the relevant bits of TUF to Guix! Comments welcome! Ludo’. ¹ https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt ² http://opam.ocaml.org/blog/Signing-the-opam-repository/ ³ https://github.com/ocaml/opam-repository ⁴ https://www.qubes-os.org/doc/verifying-signatures/ ⁵ See for example all the ‘mm_XXX’ tags at . ⁶ https://tools.ietf.org/html/rfc4880#section-5.2 ⁷ http://theworld.com/~cme/spki.txt