Could the XZ backdoor been detected with better Git/Deb packaging practices?
optimizedbyotto.com
Could the XZ backdoor been detected with better Git/Deb packaging practices?
1–10 of 116 posts
Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?
#2Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?
#3Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?
#4Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?
#5This 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>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> 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.
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?
#8How 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?
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> 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.