[Git][reproducible-builds/reproducible-website][master] gothenburg: Add d3-trusting-trust.md

[Bernhard M. Wiedemann (@bmwiedemann-guest)]

Bernhard M. Wiedemann pushed to branch master at Reproducible Builds / reproducible-website


Commits:
590083b0 by Bernhard M. Wiedemann at 2026-09-25T10:24:31+02:00
gothenburg: Add d3-trusting-trust.md

- - - - -


1 changed file:

- + _events/gothenburg2026/agenda/d3-trusting-trust.md


Changes:

=====================================
_events/gothenburg2026/agenda/d3-trusting-trust.md
=====================================
@@ -0,0 +1,51 @@
+Well known trusting trust problem:
+    Fully recursive reproducible builds
+Beyond this, there are firware and hardware dependencies that many manufacturues share (eg battery manufacturers)
+    
+    
+Current missing components or issues:
+
+    Software:
+
+    Diverse double compilation toolchain
+
+    Fully bootstraping
+
+    Source attacks (reproduction helps change the problem into source scanning which LLMs might help with)
+
+    Diverse OS and environments for compilation
+
+    Firwmware/hardware:
+
+    Battery firmware is commonly shared
+
+    CPUs, other controllers having malicious silicon
+
+
+Motivations:
+    Practical improvements to the status quo
+    
+If you use a bootstrapping chain, does that solve trusting trust?
+Practically probably but in an absoloute sense probably not because the bootstrapping chain itself is running on something untrusted
+
+    One thing to consider, a sufficiently widespread attacker (cpu backdoors) *could* tamper with reproducible builds to avoid non-reproducible packages from being detected, however an attacker with that widespread foodhold could just use their foothold to directly achieve their goals
+
+
+
+Missing piece:
+    Reproducible builds capture and share what the necessary environment details are (buildinfo files) but they do not capture or share the diversity of the build environment in the reproducible build claim
+    Reproducible builds need to share a) the minimal set of things that must be the same to reproduce (deps, source epoch) b) the actual set of things that were present (base image, firmware, cpu type, etc).
+    Goal is to have maximum diveristy in b) and minimize a)
+    
+
+Cross-ecosystem note: reproducible builds in language ecosystems frequently depend on upstream dependencies not in your ecosystem (android etc depend on compilers not produced in the android ecosystem). For most things outside Debian trusting trust is cross-ecosystem
+
+
+Particular subject of interest:
+    New self-compiling language ecosystem that Debian bootstraps by uploading binary version of compiler then iterating on that
+    
+Followup work:
+    Compile/bootstrap debian from guix and/or stagex to solve debian cyclical dependency
+    Analyzing the trees of reproducibility from current version to historical versions "reverse bootstrapping"
+    Documenting environment that's "providing diversity" rather than necessary for rebuilding
+    Trusted execution environment provides signature over the actual environment that was used to provider higher confidence in diversity



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/590083b02de96f868167817d855e891055ec6fc7

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/590083b02de96f868167817d855e891055ec6fc7
You're receiving this email because of your account on salsa.debian.org. Manage all notifications: https://salsa.debian.org/-/profile/notifications | Help: https://salsa.debian.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20260925/df4ab5c8/attachment.htm>