Ludovic Courtès writes: > 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:
[..] >>> 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 Oh indeed, has it been that long; I must have been sleeping... > >> 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! Vagrant Cascadian writes: > It was both... part of it was shipped in tests that were actually > present in git, but part of it was added in "autogenerated" bits only > present in the upstream tarball. Aah, thanks! Well that stresses Ludo's point ever harder...good! Anyway, my aversion of running generated code using bash, m4, and perl; especially where it's been known for at least 20y that plain GNU make could do the same thing without resorting to such terrible hacks is a big reason why I'm looking into BLUE (also, I have kind of a soft spot for build systems, and, well Guile :) > 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”: :-) Yes, but looking back we might have skipped this step and go straight to git-only? Oh well... > > https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/ Yes, the only point I might still disagree on is the ChangeLog (yes, git-to-changelog must be fixed, preferrably written in Guile, and until then you need to set not only timezone but also locale; well, that's doable). But it's a difficult choice, without any generated files: good, without ChangeLog: bad. Hmm. > From a principled stance of “building from source” though, the answer > will always be to start without generated artifacts. Agreed! Greetinsg, Janneke -- Janneke Nieuwenhuizen <[email protected]> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
