On Tue, Feb 10, 2026, at 6:10 PM, Ian Jackson wrote: > It's not just the xz attack that demonstrates the problem. To give > another example, treating intermediate build products - tarballs - as > source code might easily have resulted in us shipping a mystery meat > amd64 executable as part of our Rust serde package. In general, we > end up doing all manner of weirdnesses and workarounds for the > non-source stuff that's in tarballs. The practice you are advocating > applies the difference from git to to the tarball contents as an > in-practice unreviewable.
This is a red herring - binary artifacts (and other problematic files) can (and are) committed to git as well. Maintainers have to be vigilant in any case. Random example from the top of my head: https://github.com/bytecodealliance/wit-bindgen/tree/main/crates/guest-rust/src/rt (This is part of rustc transitive dep tree, and we regenerate this when building rustc in Debian[0,1]) This argument also doesn't really hold for xz-style attacks - the generated tarball just happened to be the vehicle for transporting the payload in that particular case, the same mechanism also applies to pure git packaging, just with one (of many) ways to hide the payload removed. Pure git packaging does not replace being vigilant in vetting upstreams and their sources. 0: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/debian/scripts/build-wit-bindgen.sh?ref_type=heads 1: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/debian/copyright?ref_type=heads#L50
