[Git][reproducible-builds/reproducible-website][master] rbs 2026: day2: fix formatting of notes
Holger Levsen (@holger)
gitlab at salsa.debian.org
Fri Oct 2 16:40:33 UTC 2026
Holger Levsen pushed to branch master at Reproducible Builds / reproducible-website
Commits:
a44d6e61 by Holger Levsen at 2026-10-02T18:39:52+02:00
rbs 2026: day2: fix formatting of notes
Signed-off-by: Holger Levsen <holger at layer-acht.org>
- - - - -
5 changed files:
- _events/gothenburg2026/agenda/d2-buildinfrastructure.md
- _events/gothenburg2026/agenda/d2-cross-distro.md
- _events/gothenburg2026/agenda/d2-rb-enforcement.md
- _events/gothenburg2026/agenda/d2-transparency-logging.md
- _events/gothenburg2026/agenda/d3-sourcedateepoch.md
Changes:
=====================================
_events/gothenburg2026/agenda/d2-buildinfrastructure.md
=====================================
@@ -15,9 +15,9 @@ Improve serving and format of buildinfo files
- keep buildinfo files in distro specific archives
- integrate them into the normal Debian archive pool
-- Add a pointer to the bulidinfo file to the Packages file
+- Add a pointer to the buildinfo file to the Packages file
-- Let dak check if the hashes in the buildinfo file matches the uploaded .deb
+- Let [dak](https://salsa.debian.org/ftp-team/dak) check if the hashes in the buildinfo file matches the uploaded .deb
- also syntax check, source name, version, date
- make sure that all used build dependency package version are also in the archive
=====================================
_events/gothenburg2026/agenda/d2-cross-distro.md
=====================================
@@ -8,10 +8,10 @@ permalink: /events/gothenburg2026/agenda/d2-cross-distro/
Things needed to get started as a new distribution:
-* Step 0: Pick any package, build it twice (with `SOURCE_DATE_EPOCH=123`), run diffoscope on both packages and check the package manager build tooling itself is reproducible (e.g. the tool itself doesn't record filesystem timestamps in all packages, regardless of the software you're building). Other metadata should also be identical, if the only difference is a signature we can ignore that for now.
+* Step 0: Pick any package, build it twice (with [SOURCE_DATE_EPOCH=123](https://reproducible-builds.org/docs/source-date-epoch/)), run diffoscope on both packages and check the package manager build tooling itself is reproducible (e.g. the tool itself doesn't record filesystem timestamps in all packages, regardless of the software you're building). Other metadata should also be identical, if the only difference is a signature we can ignore that for now.
* Step 1: You need an archive of old packages (e.g. a package mirror that only adds, but never deletes). If older version of build dependencies are not available anymore, we can not recreate the build environment necessary to reproduce the package
* Step 2: Document your build environment. With the archived package versions available, we now need to document which of them are needed to recreate the build environment. This list needs to include the name of all (recursive) dependencies, their versions, and it's incuraged to include a cryptographic checksum of the package file (if technically possible). The list may be embedded into the binary package (Arch Linux style), distributed along with the binary packages (Debian style), or embedded in the build log, if they are reliably retained longterm and can be parsed securely (Alpine style).
-* Step 3: Have a way to derive the `SOURCE_DATE_EPOCH` value. You may derive this from your source package (Debian style) or record a canonical reference value in the buildinfo file (Arch style)
-* Step 4: Have a build command that is able setup the reference build environment described in the buildinfo file. This also needs to ensure the `SOURCE_DATE_EPOCH` value is set accordingly.
+* Step 3: Have a way to derive the [SOURCE_DATE_EPOCH](https://reproducible-builds.org/docs/source-date-epoch/) value. You may derive this from your source package (Debian style) or record a canonical reference value in the buildinfo file (Arch style)
+* Step 4: Have a build command that is able setup the reference build environment described in the buildinfo file. This also needs to ensure the [SOURCE_DATE_EPOCH](https://reproducible-builds.org/docs/source-date-epoch/) value is set accordingly.
With all of them in place, you are good to go!
=====================================
_events/gothenburg2026/agenda/d2-rb-enforcement.md
=====================================
@@ -12,7 +12,8 @@ permalink: /events/gothenburg2026/agenda/d2-rb-enforcement/
- 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
+ - Approaches mentioned in the ["avoiding the 1%" discussion yesterday]({{ "/events/gothenburg2026/agenda/d1-longtail/" | relative_url }})
+
- repro-threshold (client side)
- a conflicts package (archive side)
- splitting repositories (archive side)
@@ -35,7 +36,7 @@ permalink: /events/gothenburg2026/agenda/d2-rb-enforcement/
- We have enough things building reproducibly to give some value to users
- - Maybe Google's CEL language is useful for policies https://cel.dev/
+ - Maybe Google's CEL language is useful for policies [https://cel.dev/](https://cel.dev/)
- Languages and language package managers have issues
=====================================
_events/gothenburg2026/agenda/d2-transparency-logging.md
=====================================
@@ -11,36 +11,36 @@ why to use transparency logs for rb:
- the results of rebuilderd, what distribution, search, merge
log backed partition maps
-patricia merkle tree
- if you transparency log is a set of keys that can be partitionned,
- for example by the partition key, and you can that into an index of this
+patricia merkle tree
+ - if you transparency log is a set of keys that can be partitionned,
+ - for example by the partition key, and you can that into an index of this
the key can be triple
- (the package name, version number, and the architecture)
- for one triple, there are many binaries,
+ - (the package name, version number, and the architecture)
+ - for one triple, there are many binaries,
what are the log entries?
- -> a hash of a binary? not only, we need the name, something else?
+ * -> a hash of a binary? not only, we need the name, something else?
content of a potential entry:
- - who is the rebuilder,
- - svc / source / package name,
- - version,
-
- then:
+ - who is the rebuilder,
+ - svc / source / package name,
+ - version,
+ - then:
arch1,binary1 -> hash1
arch2,binary2 -> hash2
we need the hash of the source in here or not?
- - the hash of the DSC file?
+ - the hash of the DSC file?
we wish this could be compatible between distros, however they have different
schemes for source, package name, version schemes... etc -- and if different
distros use the same log, how do we tell?
there are different conventions on how to name things :o)
- and different conventions on how to hash sources
+
+ and different conventions on how to hash sources
why not having a long string, that different people fill, and grow from there?
@@ -52,6 +52,7 @@ why not having a long string, that different people fill, and grow from there?
Maybe instead of a "things that looks like a map" it should be maybe
"things that look like rows in a database".
+
This would let us choose what properties we want fast lookups for *later*.
-----
@@ -99,22 +100,20 @@ but the database can be discarded or rebuild by anyone), or it can be something
-----
-one thing we didn't talk about yet
-
- when you submit the hash of the signed record format
- you get a "proof of logging" / a proof of publication
+one thing we didn't talk about yet:
+ - when you submit the hash of the signed record format
+ - you get a "proof of logging" / a proof of publication
the verifier previously, was verifying:
-
- - the signature (a rebuilderd did the rebuild)
+ - the signature (a rebuilderd did the rebuild)
the verifier would like to verify additionnaly:
-
- - the proof of publication
+ - the proof of publication
because I want to know that a rebuilder was forced to publish a result (so that if it's a bad rebuilder and trying to trick me, there is public proof of this i can point at afterwards).
after more discussion: this is an option but getting a "proof of logging" at submission time and carrying it around forever is not necessary.
+
This can also be solved by inclusion proofs in the log generated at any later time.
(And if someone will be checking more than one entry, which will probably be typical for build record inquiries (since we'd be comparing them), getting the inclusion proofs later will tend to be simpler and more efficient.)
@@ -126,22 +125,18 @@ summary of the notes, on the submit path:
2. submit BuildRecord to the log
store full record in a DataPile -- it's a CAS (log stores H(H(BuildRecord)) only)
3. mantain LookupService (for speed and usability)
- example: for example, it maps source-hash (or whatever, choose later)
- to... <---what-to-put-here--->*
+ example: for example, it maps source-hash (or whatever, choose later) to <---what-to-put-here--->
The instinct for <---what-to-put-here---> is the checksum of BuildRecord
However!
-That enables the LookupService to invent entries that don't exist in the log, if LookupService colludes with DataPile. A better picture is
-
- <---what-to-put-here--->
-
+That enables the LookupService to invent entries that don't exist in the log, if LookupService colludes with DataPile. A better picture is <---what-to-put-here--->
to be the "leaf index" (number of the entry in the log) so it forces:
- 1. go to LookupService, ask about srchash or packagename, get leaf-index
- 2. go to log with leaf-index, ask about it, get H(H(BuildRecord)) as result
- 3. go to DataPile and learn BuildRecord
+ 1. go to LookupService, ask about srchash or packagename, get leaf-index
+ 2. go to log with leaf-index, ask about it, get H(H(BuildRecord)) as result
+ 3. go to DataPile and learn BuildRecord
This makes sure that the transparency log is load-bearing during the lookups,
which addresses big picture issues like "what if people start to trust the LookupService too much in practice, and the LookupService thus becomes able to fool people in ways the transparency log is meant to prevent".
@@ -150,12 +145,12 @@ which addresses big picture issues like "what if people start to trust the Looku
On the read path:
-R1. Check lookup table for whatever property is interesting.
+ * R1. Check lookup table for whatever property is interesting.
Gives you a log entry index.
-R2. Look up the log entry index in the log.
+ * R2. Look up the log entry index in the log.
(Get log checkpoint & check witness sigs & check inclusion proof.)
Congrats, now you have H(H(BuildRecord)), verified.
-R3. Fetch full BuildRecord from DataPile, using H(H(BuildRecord)).
+ * R3. Fetch full BuildRecord from DataPile, using H(H(BuildRecord)).
(Double check that whatever property you searched for in LookupService is actually as it should be in the BuildRecord.)
With this journey, we know and verified:
=====================================
_events/gothenburg2026/agenda/d3-sourcedateepoch.md
=====================================
@@ -4,18 +4,18 @@ title: Gothenburg 2026 - Day 3 - SOURCE_DATE_EPOCH
order: 150
permalink: /events/gothenburg2026/agenda/d3-sourcedateepoch/
---
-- Bernhard proposed changes to the S_D_E spec on the rb-general list, which we discussed and found largely uncontroversial, so we went on to prepare actual MRs and propose them on the list:
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/8 links to all the others:
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/7
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/6
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/5
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/4
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/3
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/2
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/1
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/9
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/10
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/11
- - https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/12
-- In addition to that, we found the 'motivation' part of the S_D_E spec to be quite severely outdated... Now updated in MR #2
-- Announced a request for feedback in https://lists.reproducible-builds.org/pipermail/rb-general/2026-September/004165.html with a deadline of 2026-12-01
+- [Bernhard proposed changes](https://lists.reproducible-builds.org/pipermail/rb-general/2026-September/004158.html) to the [S_D_E spec](https://reproducible-builds.org/specs/source-date-epoch/) on the rb-general list, which we discussed and found largely uncontroversial, so we went on to prepare actual MRs and propose them on the list:
+ - [MR!8](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/8) links to all the others:
+ - [MR!7](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/7)
+ - [MR!6](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/6)
+ - [MR!5](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/5)
+ - [MR!4](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/4)
+ - [MR!3](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/3)
+ - [MR!2](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/2)
+ - [MR!1](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/1)
+ - [MR!9](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/9)
+ - [MR!10](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/10)
+ - [MR!11](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/11)
+ - [MR!12](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/12)
+- In addition to that, we found the 'motivation' part of the S_D_E spec to be quite severely outdated... Now updated in [MR!2](https://salsa.debian.org/reproducible-builds/specs/source-date-epoch-spec/-/merge_requests/2)
+- Announced a request for feedback in [https://lists.reproducible-builds.org/pipermail/rb-general/2026-September/004165.html](https://lists.reproducible-builds.org/pipermail/rb-general/2026-September/004165.html) with a deadline of 2026-12-01
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/a44d6e6104f44a3d500f9b02b992bb2201db2992
--
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/a44d6e6104f44a3d500f9b02b992bb2201db2992
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/20261002/511f8426/attachment.htm>
More information about the rb-commits
mailing list