[Git][reproducible-builds/reproducible-website][master] 2 commits: Convert d3-trusting-trust to markdown

Fri Sep 25 08:41:00 UTC 2026


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


Commits:
89aae0a5 by Bernhard M. Wiedemann at 2026-09-25T10:37:08+02:00
Convert d3-trusting-trust to markdown

- - - - -
ffb13a43 by Bernhard M. Wiedemann at 2026-09-25T10:38:46+02:00
d3-trusting-trust: fix typos

- - - - -


1 changed file:

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


Changes:

=====================================
_events/gothenburg2026/agenda/d3-trusting-trust.md
=====================================
@@ -1,51 +1,44 @@
-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:
+- Well known trusting trust problem:
+  - Fully recursive reproducible builds
+- Beyond this, there are firmware and hardware dependencies that many manufacturers share (e.g. battery manufacturers)
 
-    Software:
+## Current missing components or issues:
 
-    Diverse double compilation toolchain
+- Software:
+  - Diverse double compilation toolchain
+  - Fully bootstrapping
+  - Source attacks (reproduction helps change the problem into source scanning which LLMs might help with)
+  - Diverse OS and environments for compilation
+- Firmware/hardware:
+  - Battery firmware is commonly shared
+  - CPUs, other controllers having malicious silicon
 
-    Fully bootstraping
+## Motivations:
 
-    Source attacks (reproduction helps change the problem into source scanning which LLMs might help with)
+- Practical improvements to the status quo
 
-    Diverse OS and environments for compilation
+## If you use a bootstrapping chain, does that solve trusting trust?
 
-    Firwmware/hardware:
+- Practically probably but in an absolute 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 foothold could just use their foothold to directly achieve their goals
 
-    Battery firmware is commonly shared
+## Missing piece:
 
-    CPUs, other controllers having malicious silicon
+- 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 diversity in b) and minimize a)
 
+## Cross-ecosystem note:
 
-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
+- 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
 
-    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
+## Particular subject of interest:
 
+- New self-compiling language ecosystem that Debian bootstraps by uploading binary version of compiler then iterating on that
 
+## Followup work:
 
-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
+- 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 provide higher confidence in diversity



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/compare/45cda5ffdded0598f2b1da9bfe79d52609a8d9d6...ffb13a43f150f16ce63d96075ec536d791c394d7

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/compare/45cda5ffdded0598f2b1da9bfe79d52609a8d9d6...ffb13a43f150f16ce63d96075ec536d791c394d7
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/1d8398c8/attachment.htm>
