"Reproducible build" definition in OpenSSF glossary

[Leo Wandersleb]

Hi Ismael,

I think we're talking past each other. Even in the OS world, binaries are 
distributed - through apt, snap stores, flatpak, etc. When a maintainer uploads 
a .deb or someone publishes a snap, those binaries need verification.

The point of post-hoc/forensic reproducibility is being able to verify ANY 
binary matches its claimed source, regardless of whether the build system was 
designed for reproducibility. This is just as relevant for OS packages as 
anything else.

Many packaging systems (like snaps) weren't designed with reproducibility in 
mind. Post-hoc techniques are often the only way to verify what users are 
actually installing.

Reproducibility is fundamentally about transferable trust - whether that's 
between OS maintainers or between any developer and their users.

Best regards,

Leo

On 6/29/25 15:01, Ismael Luceno wrote:
> El 29 de junio de 2025 12:23:56 UTC, Leo Wandersleb <Leo at LeoWandersleb.de> escribió:
>> *2. Post-hoc/Forensic Reproducibility*Artifacts that can be reproduced even when the original author didn't specifically design for it. At walletscrutiny.com, we often reverse-engineer build processes, figure out the exact build environment, and successfully reproduce binaries that were never intended to be reproducible. This is equally valuable for security verification.
>  From the perspective of an OS this doesn't make sense because we shouldn't be taking any binaries ever, we're comparing builds among us, perhaps even just in the time domain, but definitely not with upstreams.