[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