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

Bernhard M. Wiedemann (@bmwiedemann-guest) gitlab at salsa.debian.org
Thu Sep 24 16:09:24 UTC 2026



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


Commits:
53fd55ea by Bernhard M. Wiedemann at 2026-09-24T18:09:16+02:00
gothenburg: Add d2-rb-enforcement.md

- - - - -


1 changed file:

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


Changes:

=====================================
_events/gothenburg2026/agenda/d2-rb-enforcement.md
=====================================
@@ -0,0 +1,38 @@
+## Enforcement
+ 
+ - At distro level, the gatekeeping is at entering the archive
+ - guix, enforcement can be done at client level
+ - policy attenuation, as an owner of a machine, I can set policy, can other users of the machine set policy regarding reproducible builds?
+   - And/or narrow who you trust for providing binaries
+ - Could this enforcement be made on a language level
+ - What about languages? Is it possible for authors of specific libraries to enforce reproduvible builds?
+  - Approaches mentioned in the "avoiding the 1%" discussion yesterday https://pad.riseup.net/p/rbsummmit2026-longtail
+    - repro-threshold (client side)
+    - a conflicts package (archive side)
+    - splitting repositories (archive side)
+    - ...
+  - One fustration mentioned yesterday, adding information next to the package inside the archive isn't easy
+    - If a client is looking for multiple signatures, where does the client get them from?
+    
+  - If this requires changes in the server/archive side, this can cause delays in people making use of this
+    - ATProto provides a separation between identity and storage
+    
+ - What is a success story for this? 
+   - TLS
+   - Success story for industry, proof by paperwork works less and less, need an approach that applies for companies building and distributing software
+     - If done correctly, maybe this encourages more people to build and publish signatures for software
+     
+ - Does enforcement intersect with transparency logs? For WebPKI, trust depends on the signatures being public and logged
+   - The automatic monitoring of this is a good security check, so entities can automatically check if unexpected signatures emerge, and then act if there seem to be security issues
+   
+ - Automation and being silent when things are going well as important
+ 
+ - We have enough things building reproducibly to give some value to users
+ 
+ - Maybe Google's CEL language is useful for policies https://cel.dev/
+ 
+ - Languages and language package managers have issues
+ 
+ - Who sets the safe default policy?
+   - Distro? 
+   - 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/53fd55eac938edf519db81f61c76982b9432d72e
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/20260924/debd888b/attachment.htm>


More information about the rb-commits mailing list