A backdoor in xz [LWN.net]

A backdoor in xz

Posted Mar 30, 2024 1:10 UTC (Sat) by jengelh (subscriber, #33263)
In reply to: A backdoor in xz by Cyberax
Parent article: A backdoor in xz

When people stop using curated tarballs, developers will just add generated files into the SCM. Some projects have historically done that all along anyway. I happened to find https://git.savannah.gnu.org/git/bash.git does that, for example.

Eschewing curated tarballs in favor of an autogenerated git-archive does not do anything to establish that a particular software is fully benevolent. I bet none of you ever vetted m4/po.m4 of https://github.com/bminor/bash/archive/refs/tags/bash-5.2... .

to post comments

A backdoor in xz

Posted Mar 30, 2024 1:29 UTC (Sat) by bluca (subscriber, #118303) [Link] (2 responses)

Of course by itself it doesn't prove that the software is not malicious, how could it? That's not the point, the point is increasing auditability. A commit in a repository is eminently auditable, while random stuff getting injected from a developer's machine in a tarball after the fact, before publishing, is not.

A backdoor in xz

Posted Apr 3, 2024 7:21 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (1 responses)

Well a commit that generates a configure script is very unlikely to get seriously reviewed

A backdoor in xz

Posted Apr 5, 2024 13:20 UTC (Fri) by rav (guest, #89256) [Link]

My approach to reviewing commits with autogenerated code (in the context of approving a pull request) is to autogenerate the code myself and see if I get the same result. If there are differences between the submitted code and what I could autogenerate myself, then that's probably the interesting stuff to look at. If I don't know how to autogenerate it myself, I ask the author to provide the instructions in the commit message or in a source code comment. Having autogenerated code in a source code repository is not nice, but if it's necessary, then the code review process needs to adapt to it.

A backdoor in xz

Posted Mar 30, 2024 1:52 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> When people stop using curated tarballs, developers will just add generated files into the SCM.

Most of the autogenerated files are autohell-related scripts. Honestly, if you still depend on it, you can install the required dependencies and run autogen.sh yourself on the build host. It's not 1994 anymore.

The SCM management for Bash is atrocious. We just need to switch away from it to something like zsh by default. At this point in time, doing large code drops for something as critical as Bash is just bordering on malpractice.

And relying on autohell for builds _is_ malpractice.

A backdoor in xz

Posted Mar 30, 2024 10:08 UTC (Sat) by nim-nim (subscriber, #34454) [Link] (1 responses)

The build scene is unfortunately ripe for exploits because mainstream tools are old and crufty and the FAANGS, GitHubs and GNOMEs of the world only care about giant monorepos and static builds and vendoring and containers & flatpacks which all basically mean pile up as much code as you can to avoid any dev porting effort and someone else (never defined) will somehow manage to audit the giant pile of stuff and detect malware.

Safe practices are well known that’s small auditable reusable components, that build from signed archives with no third party altered code dropped in, and frugal acyclic dependency graphs but that‘s exactly the reverse of where we’ve been doing those past years. Devs understand code modularity not build modularity.

The pile of junk has been avoiding any catastrophic collapse so far (apart from the log4j episode with every one else pretending it’s java-specific while replicating the very same build workflows) but that’s only a question of time.

A backdoor in xz

Posted Mar 30, 2024 15:09 UTC (Sat) by marcH (subscriber, #57642) [Link]

> The pile of junk has been avoiding any catastrophic collapse so far ...

Has it? With spies the main thing we know is: we know very little.

A backdoor in xz

Posted Mar 30, 2024 15:15 UTC (Sat) by gdamjan (subscriber, #33634) [Link]

> When people stop using curated tarballs, developers will just add generated files into the SCM.

There is a solution to that these days.
A Github Actions can take the tagged source code commit, generate artifacts and sign them so you do have the provenance that the artifact (tarball) was created from the given source code with the given github action.