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

Debian must ship reproducible packages

lists.debian.org

Post reply on HN
Print view View original

151–160 of 178 posts

Re: Debian must ship reproducible packages

#151

Post by theteapot »

dvogel wrote: post #132
fsflover wrote: post #119

Earlier quoted context omitted.

A distro automatically verifying that installed packages are reproducible would protect the user?

No, it wouldn't. The xzutils attacker compromised the source repository. The build pipeline portions were used to obscure the purpose of the exploit embedded in the source code repository.

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only.

Here's the quote from the guy that discovered it in the initial public disclosure [1]:

  After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer. The upstream xz repository and the xz tarballs have been backdoored. At first I thought this was a compromise of debian's package, but it turns out to be upstream. One portion of the backdoor is *solely in the distributed tarballs* and debian's import of the tarball ... it is also present in the tarballs for 5.6.0 and 5.6.1.
[1]: https://www.openwall.com/lists/oss-security/2024/03/29/4

Re: Debian must ship reproducible packages

#152

Post by dvogel »

theteapot wrote: post #151
dvogel wrote: post #132

Earlier quoted context omitted.

No, it wouldn't. The xzutils attacker compromised the source repository. The build pipeline portions were used to obscure the purpose of the exploit embedded in the source code repository.

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only. Here's the quote from the guy that discovered it in the initial public disclosure [1]: After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind erro…

You're mistaking a compromised build pipeline versus a compromised source repo that only triggers in some build pipelines. You can do reproducible builds from compromised source tarballs. Nothing about reproducible builds necessarily requires source control. Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise. However I have yet to see a reproducible build project that includes such cross-build checks.

Re: Debian must ship reproducible packages

#153

Post by deknos »

charcircuit wrote: post #129
deknos wrote: post #101

Earlier quoted context omitted.

you are free to provide patches instead of bitching.

And Debian is able to offer me a few million dollars yearly to help fix their security situation.

the idea that debian has a few million dollars to spare creates the assumption, that even if they would have... you would either not know how to fix issues, or not worth it.

Re: Debian must ship reproducible packages

#154

Post by MomsAVoxell »

PunchyHamster wrote: post #134
MomsAVoxell wrote: post #62

Earlier quoted context omitted.

“Hasn’t happened” is quite naive. It happens internally - putting unscrupulous code in a company’s distro before torching the place is a surprisingly regular occurrence in places which have long since adopted Debian as a platform host. IT departments around the globe will benefit from this immensely.

And reproducible builds do not prevent that. The one single fail point they prevent is infected build hosts. That might be some reasonable benefit for the company if it is building it on public architecture, but for projects like Debian that insist build hosts are basically offline (package in, package out with no internet access during build process) it is very fringe benefit.

Nonsense, of course reproducible builds can be used by IT departments to catch nefarious behavior - they regularly do.

Re: Debian must ship reproducible packages

#155

Post by MomsAVoxell »

murderfs wrote: post #84
MomsAVoxell wrote: post #61

Earlier quoted context omitted.

Why should it only be valuable if the effects were to be publicly known? There are plenty of places in industrial computing where reproducible builds have prevented subterfuge within the organizations themselves. Injecting binaries to do inf-/exfiltration is a long-standing industrial espionage activity which is of immense value to all users of the operating system - not just the consumer users.

My magic beans have prevented thousands of tiger attacks in top secret underground moon bases, never you mind that there's no way for me to actually prove this. There's a certain irony in pushing for verifiable builds with completely unverifiable claims. I've worked at several of the biggest targets for espionage, industrial or otherwise, and to the best of my knowledge, the only thing that's ever been discovered by…

You probably don’t have enough experience with professional enterprise IT departments. Rootfs audits are a thing made a lot easier, and more effective, with reproducible builds.

Re: Debian must ship reproducible packages

#156

Post by MomsAVoxell »

bluGill wrote: post #79
MomsAVoxell wrote: post #76

Earlier quoted context omitted.

Those problems need to be solved as well.

I don't think they do, actually. Longevity sounds good, but in reality anything that's old probably has critical security holes and so you shouldn't use it anyway.

You’re not thinking like an industrial user but rather as a consumer. Maybe you should extend your scope a little bit.

Re: Debian must ship reproducible packages

#157

Post by MomsAVoxell »

PunchyHamster wrote: post #138
iamnothere wrote: post #91

Earlier quoted context omitted.

A warning is sufficient. Old tech should continue to work, for preservation and archival reasons.

just archiving binary artifacts and source packages is enough Reproducibility adds nothing here

It sure does: no need to keep the binaries around if they are reproducible.

Re: Debian must ship reproducible packages

#158

Post by MomsAVoxell »

PunchyHamster wrote: post #137
MomsAVoxell wrote: post #57

Earlier quoted context omitted.

Reproducible builds are applicable not only to respond to ‘attacks’, a subject you seem to be bikeshedding, but also for other reasons too. Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go. Reproducible builds are about longevity as much as they are about security . Please don’t make bold claims about ‘no reason a…

> Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go. Just baking in build ID and commit is enough. What you think reproducible builds add ? > Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computin…

I already gave you an example, you dismissed it because you know better, but it is clear that you haven’t thought this through from the perspective of systems designers who have to deploy a base OS, with expected lifetimes of years, across a large fleet of devices.

Think industrial applications, such as rail and heavy industry transportation. We use reproducible builds here as part of a wider safety-critical protocol which guarantees that what we are running is what we expect to run - nothing more, nothing less.

Reproducible builds are certifiable. They can be relied on in environments where certification costs millions and takes years.

Think outside your consumer box for a minute.

Re: Debian must ship reproducible packages

#159

Post by uecker »

dvogel wrote: post #152
theteapot wrote: post #151

Earlier quoted context omitted.

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only. Here's the quote from the guy that discovered it in the initial public disclosure [1]: After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind erro…

You're mistaking a compromised build pipeline versus a compromised source repo that only triggers in some build pipelines. You can do reproducible builds from compromised source tarballs. Nothing about reproducible builds necessarily requires source control. Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise. However I have ye…

Nowadays you would work in git and then you would be able to easily detect any discrepancy between the upstream tar ball and the upstream source imported via git. But yes, better support for securing more of the process is needed.

Re: Debian must ship reproducible packages

#160

Post by theteapot »

dvogel wrote: post #152
theteapot wrote: post #151

Earlier quoted context omitted.

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only. Here's the quote from the guy that discovered it in the initial public disclosure [1]: After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind erro…

You're mistaking a compromised build pipeline versus a compromised source repo that only triggers in some build pipelines. You can do reproducible builds from compromised source tarballs. Nothing about reproducible builds necessarily requires source control. Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise. However I have ye…

> Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise.

Good. Then we are on the same page.

Post reply on HN