A smaller, more trustable tarball
A smaller, more trustable tarball
Posted Mar 24, 2025 9:17 UTC (Mon) by farnz (subscriber, #17727)In reply to: A smaller, more trustable tarball by epa
Parent article: Julien Malka proposes method for detecting XZ-like backdoors
Even better would be to work (with upstream if it's an upstream thing) to break the cycle; for example, the article describes how autoconf requires xz, but you can't build xz from source control without autoconf. When I look at upstream autoconf however, you can build an untested autoconf without xz; it only needs xz to test that its probing works.
With considerable effort, you could "break apart" the autoconf dependency, and have a setup where the autoconf package build instructions know how to build it with a minimal set of dependencies, and redo part or all of the build and test process each time a new dependency is build. That way, you still don't need to depend on a tarball, but you're now in a position to build from Git, Mercurial or other sources that you can extract a Merkle tree from, blocking off the Jia Tan attack vector.
You still face the issue that an attacker might not try to be as stealthy as Jia Tan attempted to be (and just puts the backdoor in source control), but that's hopefully an easier attack vector to close off than the one that was attempted.
Posted Mar 24, 2025 9:57 UTC (Mon)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Mar 24, 2025 10:36 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
The hard part of such a system is determining the minimum set of builds needed for everything to work; you don't want to keep rebuilding autoconf when you can wait for more packages to be installed safely. But that's a mix of a hard metadata problem (if I need autoconf that supports erlang, I must declare that I depend on erlang) and a solved graph theory problem (extracting a build tree from a dependency graph, given rebuilds).
Posted Mar 24, 2025 20:05 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
`xz` also supports being built with CMake which would break this cycle: <https://github.com/tukaani-project/xz/blob/master/CMakeLi...>. CMake can bootstrap itself where it generates a "minimal CMake" using a shell script to drive a basic compilation enough to compile the rest of CMake itself (though this doesn't work on Windows; an existing CMake is needed there).
A smaller, more trustable tarball
You could gold-plate the system further, and only have a single autoconf package that knows how to self-update as more dependencies are installed. Then, you install autoconf with minimal dependencies; you install xz, gccgo, erlang and other dependencies, then update autoconf to pick up the newly available dependencies, which triggers a rebuild not just of autoconf itself, but also anything that depended on the old build of autoconf.
A smaller, more trustable tarball
A smaller, more trustable tarball