[Git][reproducible-builds/reproducible-website][master] d3-trusting-trust: improve grammar

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

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


Commits:
1020953b by Bernhard M. Wiedemann at 2026-09-25T11:26:59+02:00
d3-trusting-trust: improve grammar

- - - - -


1 changed file:

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


Changes:

=====================================
_events/gothenburg2026/agenda/d3-trusting-trust.md
=====================================
@@ -1,4 +1,4 @@
-- Well known trusting trust problem:
+- 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)
 
@@ -7,7 +7,7 @@
 - Software:
   - Diverse double compilation toolchain
   - Fully bootstrapping
-  - Source attacks (reproduction helps change the problem into source scanning which LLMs might help with)
+  - 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
@@ -19,26 +19,26 @@
 
 ## If you use a bootstrapping chain, does that solve trusting trust?
 
-- 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
+- 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
 
 ## 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 diversity in b) and minimize a)
+- 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) and b) the actual set of things that were present (base image, firmware, CPU type, etc.).
+- The goal is to have maximum diversity in b) and to 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
+- Reproducible builds in language ecosystems frequently depend on upstream dependencies that are 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
+- A new self-compiling language ecosystem that Debian bootstraps by uploading a binary version of the 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 provide higher confidence in diversity
+- Compile/bootstrap Debian from Guix and/or StageX to solve Debian's cyclical dependency
+- Analyzing the trees of reproducibility from the current version to historical versions ("reverse bootstrapping")
+- Documenting the environment that's "providing diversity" rather than necessary for rebuilding
+- A trusted execution environment provides a 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/-/commit/1020953b01b75e8f579d399f7525636e0f212909

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/1020953b01b75e8f579d399f7525636e0f212909
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/fc78a8e4/attachment.htm>