El 29 de junio de 2025 19:58:58 UTC, Leo Wandersleb <[email protected]> escribió: >On 6/29/25 21:51, Ismael Luceno wrote: >> El 29 de junio de 2025 13:58:24 UTC, Leo Wandersleb <[email protected]> >> escribió: >>> 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. >> A wider definition threatens with a chasing game we don't want to play with >> upstream authors. >> >> We want people to, ideally, fix their buildsystems, and maintain that >> support forward. >> >> At some point it can be made a requirement, we don't expect to do any >> reverse engineering, and we don't want it to be an afterthought in the >> future. >> >> A narrow definition keeps those problems at bay as inherently out of scope. >> >> Binary distributions should aim for the same experience source based >> distributions have been providing for 25 years, binary packages should act >> like an optimisation to skip the build more or less. >> >> So it isn't about verifying the work of any single maintainer, but ideally a >> distributed check on the whole ecosystem. >> >> Does that make sense? > >I agree that the goal must be to have apps be built such that checking a >binary is as trivial as possible but reproducing a build also does happen >outside of projects that design their build to be reproducible and we at >WalletScrutiny do that. We warn users about failure to reproduce a binary >which hopefully is an incentive to providers to care more about >reproducibility.
Isn't upstream not caring enough of a red flag?
