[Git][reproducible-builds/reproducible-website][master] gothenburg: Add d3-rb-enforcement2.md

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

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


Commits:
3b486f98 by Bernhard M. Wiedemann at 2026-09-24T18:13:46+02:00
gothenburg: Add d3-rb-enforcement2.md

- - - - -


1 changed file:

- + _events/gothenburg2026/agenda/d3-rb-enforcement2.md


Changes:

=====================================
_events/gothenburg2026/agenda/d3-rb-enforcement2.md
=====================================
@@ -0,0 +1,41 @@
+Follow-up of a [session on day 2](d2-rb-enforcement.md)
+
+ - Distro policy, where reproducible builds block updating packages
+   - People can bypass this by asking for things to 
+ - Client side enforcement
+ - Where can we put enforcement? How do we move information around?
+ - Meta-enforcement, EU?, software that offers public services should be open source and build reproducibly
+  - There's a German startup which helps with reproducible docker images (Zendis, L3monTree, devguard.org)
+ - State in Arch at the moment, 70% at the moment is reproducible, so enforcing client side would break installs
+ - Fallback building from source
+ - People don't care about reproducibility, they care about trust
+ - Profile guided optimisation is still an issue, but distros already target a broad range of hardware support over speed
+ - Focusing on the client side experience is good, then you can work backwards to inform other things
+ - What do you expect to happen if some core package is non-reproducibe?
+   - One idea, some kind of poilcy, with exceptions to handle this case
+   - Users might need software that doesn't build reproduucibly, so they might feel that they don't have a choice
+ - There's a need to handle this on a ongoing basis, since reproducibility issues will still crop up in the future
+ - There's some benefits already from reproducible builds, e.g. small fixes don't have uninteded consequences
+ - Maybe a downside with client side verification can lead you with an inconsistent repo state
+   - You could have a setup where non-reproducible packages are held back, rather than being shown to clients but not being installable
+ - What are the unsolved problems with the space, on both the client and server side?
+   - How should users see this, if at all, how should failures be surfaced?
+   - On a distro level, many distributions don't have a policy on reproducible builds
+   - Lack of tooling on the client side
+   - Protocol definitions, e.g. rebuilderd interoperating with oss-rebuild
+   - Should clients connect out to find signatures from the different sources they trust, or should these be batched up?
+   - Can transparency logs be used?
+   - Handling the remaining 1% non-reproducible things.
+ - Path forward with profile guided optimisation?
+   - In Debian, maybe two paths forward, accept some non-reproducible packages, fix the non-reproducibility
+ - For source based distros, Guix, Nixpkgs, Gentoo, ... some of these problems are easier to get around, since you can fall back to building from source
+ - TLS is a helpful model here. 
+ - Practical issues on verifying reproduuucibility
+   - Verifiers go down
+ - Is it enough to claim that all a distro's packages are reproducible?
+ - How do things work for 3rd party repositories?
+ - Policy on a package level?
+   - Exceptions on a package level
+ - APT implementation details
+ - Easy sketch
+ - How does this work for airgaped environments?



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/3b486f9815704d69f66528f8aeed0325dbe72faf
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/1507e757/attachment.htm>