"Reproducible build" definition in OpenSSF glossary
Arnout Engelen
arnout at bzzt.net
Wed Jul 2 08:58:00 UTC 2025
On Wed, Jul 2, 2025, at 09:23, Simon Josefsson wrote:
> "Arnout Engelen" <arnout at bzzt.net> writes:
> > I agree "Reproducible Builds" as a whole means "from source to binary".
>
> That would make Debian installer CDs impossible to call reproducible,
> since they are built from binaries for which we do not have source code.
Right: I'd call the "Debian installer CD build process" reproducible, and the "Debian installer CD" artifacts themselves "Reproducible, except for binary blobs X, Y and Z" (assuming the packages that are on the installer CD are reproducible)
FWIW, I think Roland's updates on the progress in this area are great and represent the achievements and limitations accurately, I don't think they'd be 'wrong' (at most perhaps using terms 'colloquially')
> So while I really agree with your goal, and would like that to exist
> (distributions like Trisquel is a way forward here), I'm not sure
> throwing out the baby (Debian) with the bath water here is a good idea.
I don't think this interpretation throws out Debian. You don't need to go all-Trisquel as most of the non-reproducible dependencies will be in the 'environment', not in the 'sources'.
> > As for Leo's efforts painstakingly recreating a binary where upstream
> > isn't interested in reproducible builds: I can see how it's useful,
> > but I don't think it's "reproducible builds": a 'reproducible build'
> > implies a repeatable process, not a one-off verification. Moreover
> > when "signatures or compression might differ" that further deviates
> > from "Reproducible Builds". I think it might still be reasonable for
> > them to say "we have reproduced this artifact" (though 'recreated'
> > might be clearer?), but it should not link to "Reproducible Builds".
>
> Are you talking about upstreams who publish source+binaries or only
> sources? If upstream publish source code only, the whole concept of
> "reproducible build" is mostly outside of their scope (to produce source
> code), and I think we could talk about a reproducible build.
I'm talking about taking a binary artifact, and then doing a post-hoc/'forensic' recreation from sources to verify that binary does not have unexpected things in it. That, to me, is useful but not 'reproducible builds'. I'm not sure it matters if that binary was produced upstream or by a 3rd party.
I agree for projects that only publish sources, 'reproducible builds' is somewhat out of their scope, though 'making sure their downstreams can build the project reproducibly' (if there is such a thing) could still make sense there.
--
Arnout Engelen
Engelen Open Source
https://engelen.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20250702/98655013/attachment.htm>
More information about the rb-general
mailing list