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 <[email protected]>
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.
