Collaborative Working Sessions - Local reproducibility
Local reproducibility and user perception
- How can I check the provenance of the software on my own machine?
- What does it even mean to show RB status to the user?
- Arch has a checkbox
- F-Droid’s Reproducibility Status link https://verification.f-droid.org/packages/org.fdroid.fdroid/
- How to give users choices based on RB?
- What does RB mean even?
- RB is impossible, you can only succeed in trying at the moment
Example for 3: CPU instruction sets can change builds, newer CPUs might make binary diff
-
Users are probably most interested in that binary matches source.
- for most users, RB is really only part of the brand, and has no other meaning
-
Arch setup is that builds are flagged, then users can repro themselves locally
- RB could be represented as an action rather than a status: run this build process, click to read the diff, etc.
track source tarballs https://whatsrc.org/artifact/sha256:5dc926f8306473c33082fc4fdd3356207e5874f91c00c0d76125f26ce35bbe1b
- limited orgs care about RB
- limited amount of people care about RB
-
when the general FOSS ecosystem is already RB enough, others will adopt because its easy and necessary to maintain a trusted brand
-
lots of distros don’t care about RB because it does not fit in with their business model
- bringing in “trust” to the conversation kills the possibility to improve RB
takeaways
- comms for RB to users can be improved
- definition for reproducibility can be clarified by letting distros define how they do it
