Re: RFC: Check for reproducible builds.

[ericonr <ericonr@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/pull/30588#issuecomment-830478097

Comment:
> We shouldn't improve deterministic builds because we don't have deterministic builds. I don't see how that's a valid reason.

The point is that the checksum won't match in 100% of the cases because of the metadata (specifically `source-revisions` - when you update the template with the new checksum for the package, that will change the commit hash and therefore the checksum; it's a loop). Most (all?) reproducible builds projects start from a binary artifact produced by the build and check if they can re-generate that based on information they had about the build environment, instead of checking if the builder produced the expected binary. I believe guix tries to check checksums from the bootstrap build process, but they always start from 0, which is a very different situation than what we have.

The determinism I was talking about wasn't in the sense of reproducible-builds, but in the sense that we can't control the value of `source-revisions` until the package has been built.

> There are problems with changing metadata, but there are ways around this. We have all the moving parts available and can work on them.

Which is why I'm proposing to study them. A content checksum (like our `@hash` checksum for templates) that skips `props.plist` would do most of the work (though it'd be slower). The issue then would be how to enforce policy to make people build packages for all archs, with the same settings used by builders (and then you have to take into account that `SOURCE_DATE_EPOCH` is derived from when a template was last touched, and that's also a loop of information, because a commit with a different date will once again alter the date, and this value *can* appear in normal files, for things like "build time"; this should be a rare case, though).

I don't think we have resources for a package archive or a "rebuilder" server that just tries to rebuild packages on its own, but I don't think the added workload and noise ("is this checksum wrong because someone forgot to udpate it or because something changed?") makes it worth having reproducible builds tracked in this repository. I would gladly contribute to a separate repository that tracks "verifications" from void users, and we could figure out some way to calculate "hashes" that skip the difference caused by building from different commits (which would, unfortunately, partly defeat the purpose of reproducible-builds: to be able to verify that packages are exactly the same by simply comparing hashes from raw archives, without complicated tools).

To be clear, I am very interested in this work, and would like to see Void more reproducible (and have its reproducibility quantified as well). But I don't think this is a correct direction.