Live data from Hacker News

Could the XZ backdoor been detected with better Git/Deb packaging practices?

optimizedbyotto.com

1–10 of 116 posts

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#2
How did the changes in the binary test files tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma, and the makefile change in m4/build-to-host.m4) manifest to the Debian maintainer? Was there a chance of noticing something odd?

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#5
> As of today only 93% of all Debian source packages are tracked in git on Debian’s GitLab instance at salsa.debian.org. Some key packages such as Coreutils and Bash are not using version control at all

This bends my brain a little. I get that they were written before git, but not before the advent of version control.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#6
It shouldn't have happened in the first place. OpenSSH should control their exact dependencies and Debian shouldn't be meddling with them and swapping them out, loading random code into OpenSSH's process.

>we can only trust open source software. There is no way to audit closed source software

The ability to audit software is not sufficient, nor neccessary for it to be trustworthy.

>systems of a closed source vendor was compromised, like Crowdstrike some weeks ago, we can’t audit anything

You can't audit open source vendors either.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#7
post #5

> As of today only 93% of all Debian source packages are tracked in git on Debian’s GitLab instance at salsa.debian.org. Some key packages such as Coreutils and Bash are not using version control at all This bends my brain a little. I get that they were written before git, but not before the advent of version control.

> I get that they were written before git, but not before the advent of version control.

  git clone https://git.savannah.gnu.org/git/bash.git
  git clone https://git.savannah.gnu.org/git/coreutils.git
Plug the repo name into https://savannah.gnu.org/git/?group= to get a link to browse the repo.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#8
post #2

How did the changes in the binary test files tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma, and the makefile change in m4/build-to-host.m4) manifest to the Debian maintainer? Was there a chance of noticing something odd?

mostly no, from my reading - it was a multi-stage chain of relatively normal looking things that added up to an exploit. helped by the tests involved using compressed data that wasn't human-readable.

you can of course come up with ways it could have been caught, but the code doesn't stand out as abnormal in context. that's all that really matters, unless your build system is already rigid enough to prevent it, and has no exploitable flaws you don't know about.

finding a technical overview is annoyingly tricky, given all the non-technical blogspam after it, but e.g. https://securelist.com/xz-backdoor-story-part-1/112354/ looks pretty good from a skim.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#9
post #5

> As of today only 93% of all Debian source packages are tracked in git on Debian’s GitLab instance at salsa.debian.org. Some key packages such as Coreutils and Bash are not using version control at all This bends my brain a little. I get that they were written before git, but not before the advent of version control.

Specifically the packaging is not in version control. The actual software is, but the Debian maintainer for whatever reason doesn't use source control for their packaging.
Post reply on HN