Binary Distribution Rebuilds | Hacker News Reader

Binary Distribution Rebuilds

blog.josefsson.org

30 pointsJNRowe5 comments

> PS. I fear that Debian main may have already went into a state where it is not able to rebuild itself at all anymore: the presence and assumption of non-free firmware and non-Debian signed binaries may have already corrupted the ability for Debian main to rebuild itself. To be able to complete the idempotent and bootstrapped rebuild of Debian, this needs to be worked out.

Are any nonfree packages used as build inputs? If not, just ("just") bootstrap guix on a blobless platform, and cross build Debian from that

As an alternative to Guix with a much more strict supply chain security policy, consider: https://stagex.tools/

Thanks, that's really cool. Have you used this? Does it work well and are there pain points to look out for? A necessarily hosted system strikes me as not exactly covering a full Trusting Trust situation (because the host can compromise it) but it otherwise looks really solid at a glance.

I use it for all my projects at several orgs, with several languages. I am the founding engineer of the project so I am likely a bit biased on ideal developer UX though.

Just drop a Containerfile in your project with pinned hashes of all dependencies and you will likely get deterministic results of your own software basically for free.

Here are some standalone projects that are built deterministically with stagex:

- https://codeberg.org/stagex/repros

- https://git.distrust.co/public/airgap

- https://git.distrust.co/public/enclaveos

- https://github.com/tkhq/quorumos

- https://github.com/siderolabs/toolchain/blob/main/Pkgfile#L5...

- https://github.com/MystenLabs/sui/blob/main/docker/sui-node-...

- https://github.com/tkhq/tkcli/blob/main/src/Dockerfile

> How big is N today? The simplest assumption is that it is infinity. Any build timestamp embedded into binary packages will change on every iteration. This will cause the process to never terminate. Fixing embedded timestamps is something that the Reproduce.Debian.Net effort will also run into, and will have to resolve.

This was addressed by the Debian reproducible build project years ago. We’re down to 2.2% of packages that are not reproducible. Even if this uses a different definition, it certainly means that the majority of packages do not have a build timestamp problem.

I’m struggling to make sense of this article and I’m a Debian Developer. I think part of the problem might be that the author isn’t aware of the huge progress Debian has already made in this area over many years.

Reply on news.ycombinator.com