Janneke Nieuwenhuizen <[email protected]> skribis: > Ludovic Courtès writes: > >> During the Guix Days session about bootstrapping¹, I suggested that we >> finally bite the bullet and avoid building from tarballs that contain >> pre-built binaries—typically autotools-generated files, Info files, >> sometimes HTML or PDF files. >> >> There are several reasons: >> >> 1. We go to (very) great lengths to build everything from source, and >> this exception had become the elephant in the room. Debian and >> live-bootstrap (among others) paved the way. >> >> 2. Tarballs that include generated code are an attack vector, as we >> have seen with XZ-Utils. >> >> 3. Not the main motivation, but it turns out that archiving and >> retrieving Git checkouts from SWH is less convoluted than dealing >> with tarballs. >> >> I have created a milestone to keep track of progress: >> >> https://codeberg.org/guix/guix/milestone/66679 >> >> There’s a laborious but easy part with packages close to the leaves. >> And then there are trickier parts close to the root, in >> ‘commencement.scm’—though again we can take inspiration from >> live-bootstrap for these. >> >> If we eventually replace many tarballs with ‘git-fetch’, then we’ll have >> to require a version of guix-daemon recent enough to have >> “builtin:git-download”, to break the cycle. >> >> Thoughts? > > We discussed it, and I'm very happy with this--possibly somewhat bold?--move, > thanks!
It is bold but I think it’s been on the table for years. :-) https://lists.gnu.org/archive/html/guix-devel/2024-09/msg00175.html https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00028.html https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00226.html > As a slightly [un]related note though, wasn't the XZ-Utils attack made > primarily in Git, or was the creation of a tarball involved? Not to say > that running the auto*tools generated code is bad, and could "easily" be > backdoored (more easily than to hide it in the auto*tools source files). Yes, a large part of it was social engineering, which led to the introduction of specially-crafted binary files in the repo. The tarball, then would include a slight difference in its generated files that would take advantage allow ./configure (I think?) to run these binaries. https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 So you’re right: autotools were not the only thing that made the backdoor possible, they’re just one enabler (through obfuscation) in a complex chain of events. Still good to address it though! Of course another approach is reproducible tarballs, which you looked at (and implemented!) in the past couple of years. Or what Simon Josefsson calls “minimal source-only tarballs”: https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/ >From a principled stance of “building from source” though, the answer will always be to start without generated artifacts. Thanks, Ludo’.
