Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

optimizedbyotto.com

Post reply on HN
Print view View original

21–30 of 116 posts

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

#21

Post by goodpoint »

flerchin wrote: 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.

The author is incorrect. Keeping the packaging files under git is done out of convenience but it does not help for security and reproducibility.

The packages uploaded in Debian are what matters and they are versioned.

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

#22

Post by IshKebab »

charcircuit wrote: post #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 w…

That's really incidental. There are a gazillion vectors for exploitation once you control a package like xz. You can't fix this issue by plugging them one by one.

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

#24

Post by ottoke »

simoncion wrote: post #7
flerchin wrote: 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.

This is the upstream source control. The article talks about the Debian packaging source not being in git (on e.g. salsa.debian.org).

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

#25

Post by 1718627440 »

charcircuit wrote: post #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 w…

> Debian shouldn't be meddling with them

Debian is the OS, and the OS vendor should decide and modify the components it uses as a foundation to create the OS as he desires. That's what I am choosing Debian for and not some other OS.

> You can't audit open source vendors either.

What defines open source, is that you can request the sources for audit and modification, so I think this statement is just untrue.

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

#26

Post by oivey »

kryptiskt wrote: post #11
simoncion wrote: post #7

Earlier quoted context omitted.

> 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.

Look at the commit log in the bash repo. What good does it do if it notionally is version controlled if the commits look like this: 2025-07-03 Bash-5.3 distribution sources and documentation bash-5.3 Chet Ramey 896 -103357/+174007

Ahh yes, if only the commit message was better. That would have stopped the xz attack.

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

#27

Post by rcxdude »

1970-01-01 wrote: post #20

>Can we trust open source software? Yes — and I would argue that we can only trust open source software. But should we trust it? No!! That's why we're here! I'm not satisfied with the author's double-standard-conclusion. Trust, but verify does not have some kind of hall pass for OSS "because open-source is clearly better." Trust, but verify is independent of the license the coders choose.

Yes, I would say that being able to view the source code and build it yourself is a necessary but not sufficient condition of properly trusting the software. (which is not quite the same thing as it being open source, but it's relatively rare outside of being a very big customer that you can do this for non-open-source code).

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

#28

Post by rcxdude »

oivey wrote: post #26
kryptiskt wrote: post #11

Earlier quoted context omitted.

Look at the commit log in the bash repo. What good does it do if it notionally is version controlled if the commits look like this: 2025-07-03 Bash-5.3 distribution sources and documentation bash-5.3 Chet Ramey 896 -103357/+174007

Ahh yes, if only the commit message was better. That would have stopped the xz attack.

It's not just the commit message, but the fact that it's a single commit with >100k lines changed (though, if that's just a merge commit, it might be not super unusual for that kind of workflow. Though big merge commits are a good place to hide things in git, given that they can introduce their own changes)

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

#29

Post by simoncion »

ottoke wrote: post #24
simoncion wrote: post #7

Earlier quoted context omitted.

> 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.

This is the upstream source control. The article talks about the Debian packaging source not being in git (on e.g. salsa.debian.org).

Eh, I didn't bother to read TFA. So, it was ambiguous as to whether OP was talking about the projects or Debian's packages of the same. I figured it was more likely that OP was talking about the projects and proceeded accordingly.

If that quote's about keeping Debian packaging in source control, I don't really see much benefit for packages like coreutils and bash that generally Just Work(TM) because they're high-quality and well-tested. Sign what you package up so you can detect tampering, but I don't see you really needing anything else.

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

#30

Post by crote »

goodpoint wrote: post #21
flerchin wrote: 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.

The author is incorrect. Keeping the packaging files under git is done out of convenience but it does not help for security and reproducibility. The packages uploaded in Debian are what matters and they are versioned.

And how are you supposed to verify that the right packages have been uploaded?

The easiest way to verify that is by using a reproducible automated pipeline, as that moves the problem to "were the packaging files tampered with".

How do you verify the packaging files? By making them auditable by putting them in a git repository, and for example having the packager sign each commit. If a suspicious commit slips in, it'll be immediately obvious to anyone looking at the logs.

Post reply on HN