[Git][reproducible-builds/reproducible-website][master] gothenburg: Add d2-rb-security.md

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

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


Commits:
bc884a1d by Bernhard M. Wiedemann at 2026-09-25T10:21:49+02:00
gothenburg: Add d2-rb-security.md

- - - - -


1 changed file:

- + _events/gothenburg2026/agenda/d2-rb-security.md


Changes:

=====================================
_events/gothenburg2026/agenda/d2-rb-security.md
=====================================
@@ -0,0 +1,27 @@
+# Security and RB
+
+- Should we distinguish between using reproducibility to detect non-malicious vulnerabilities vs. malicious activity?
+  - Are we using this proactively or reactively?
+  - Are we trying to prevent bad behavior, or just log it for others?
+
+- Two related but different aspects: reducing implict trust in build pipelines, and distributing trust assumptions amongst different parties to reduce vulnerability against malicious actors.
+
+- A big problem - reproducibility is source + build environment. What can we do to pin/communicate the build context?
+  - system transparency
+  - hardware trust protocols / 2-phase signing - only sign hardware-signed builds
+  - N of M quorums amongst independent build servers
+
+- Another big problem - how to establish/maintain trust?
+  - how do we get rebuilders?
+  - how many do we actually need?
+  - what do to bad rebuilders, both accidentally bad (unreliable) or intentionally bad (i.e. sybil attack)
+  - how do we deal with the evolution of policies over time, i.e. expand/reduce quorum out of necessity?
+
+- Trust all the way down
+  - 4 "layers" - developer, software, hardware operator, hardware itself
+  - Pushing risk out of software and into hardware is still a practical risk reduction
+
+- What to do when reproducibility fails?
+  - what "level" of reproducibility do we care about?
+  - is every reproducibility failure worth reporting?
+  - should we look for "middle ground" policies between binary allow/reject decision for non-reproducible software?



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

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