Making reproducible builds & GitBOM work together in spite of low-level component variation
ludo at gnu.org
Mon Jun 27 12:19:39 UTC 2022
Vagrant Cascadian <vagrant at reproducible-builds.org> skribis:
> I can see the value in embedding provenence information in the build
> artifacts, but that makes reproducible builds considerably harder to
> achieve if it is recording *everything* about the build environment.
I think this raises an important question: should provenance information
be recorded within build outputs, or should it be kept out-of-band?
There’s value in having provenance data in-band: that makes binaries
But it also has a downside: commit IDs, like timestamps, don’t
contribute anything to the build result; I can build the same thing from
a different commit and get the exact same build result. By storing
commit IDs in the output, we’re producing gratuitous discrepancies
between builds that would otherwise produce bit-identical output².
We should make sure embedded commit IDs do not become the new timestamp.
¹ Guix stores provenance data in-band in one case, for system
deployment, such that ‘guix system describe’ can tell you which commit
you used to deploy your system.
² For that reason, ‘guix pack’ does not store provenance data by
default; see discussion of ‘--save-provenance’ at
More information about the rb-general