You clone a Git repository, then pull from it. How can you tell its contents are “authentic”—i.e., coming from the “genuine” project you think you’re pulling from? With commit signatures and “verified” badges ✅ flourishing, you’d think this has long been solved—but nope! This is in essence the problem GNU Guix, as a software deployment tool and GNU/Linux distribution, had to solve as we will see in this talk. A key element of supply chain security is updates: how can we make sure software updates are secure? That one doesn’t risk running malicious software when updating software their system? For free system distributions, The Update Framework (TUF) has become a reference on these matters. However, TUF is designed with binary distributions in mind—think Debian or even PyPI—and is not suite for “source distributions” like GNU Guix. In this talk I will present how Guix distributes software packages and the mechanisms central to supply chain security in Guix: reproducible builds, builds from source (the “full-source bootstrap”), and provenance tracking. Software updates in Guix amount to ‘git pull’ so the security of updates translates to the ability to authenticate Git checkouts. Believe it or not, this pretty fundamental problem was still in search of a solution. Guix developed a simple mechanism for Git authentication, which has been used in production for a couple of years. I will present it and, given that the solution is generic, show how it could benefit Git users alike. We’ll also reflect on how Guix’s approach compares to those developed by tools like slsa or in-toto.