A backdoor in xz [LWN.net]

A backdoor in xz

Posted Mar 30, 2024 13:45 UTC (Sat) by smurf (subscriber, #17840)
In reply to: A backdoor in xz by salimma
Parent article: A backdoor in xz

Debian's "orig.tar.gz" is itself an anachronism that should be tossed into the garbage bin of history sooner rather than later.

They should check out the appropriately-tagged "debian" git branch, build binaries, package them. Done. No more "grab an orig.tar which you didn't build, then apply patches with poissibly-traceable provenance" dances. PLEASE.

to post comments

A backdoor in xz

Posted Apr 1, 2024 5:19 UTC (Mon) by ras (subscriber, #33059) [Link] (1 responses)

> They should check out the appropriately-tagged "debian" git branch, build binaries, package them. Done.

I get what you saying when talking about patches done to the source. Asking git to apply a series of commits is generally much easier then doing the same thing with quilt or whatever.

However, a git repository and git commits aren't in my opinion source code. Which is to say they aren't a program developers can inspect and modify that reproducibly takes pristine upstream source as input, and produces the source that will be distributed and compiled to produce the Debian binary package as output. That's the sort of thing you need to make the process auditable. It's what uscan and patches produce.

Debian does have tools that take a git repository and spit out the debian source packages in an auditable format - and yes that includes the .orig.tar.gz plus patches. Isn't that enough?

A backdoor in xz

Posted Apr 1, 2024 9:39 UTC (Mon) by smurf (subscriber, #17840) [Link]

> However, a git repository and git commits aren't in my opinion source code.

Source code is defined as the preferred format to use when you want to work on the code in question. I submit that these days the number of upstream authors of nontrivial packages whose workflow consist of "while buggy: edit compile debug", followed by "edit version# && make clean && tar cfz && upload", is essentially zero.

Thus it seems like a good idea to use the code that's actually checked into upstream's version control as a basis for automated building of a distribution's binaries *and* the sources it needs to provide, for copyleft-right-and-center reasons if nothing else. Instead of ignoring upstream's git archive and basing the build on some unsigned tarball somebody created somehow.

Mostly-seamless conversion from upstream-plus-patches to Debian-branch-of-git-archive and back is pretty straightforward these days, thanks to dgit and related tools.