[Git][reproducible-builds/reproducible-presentations][master] WIP: Reproducible Builds: A Trustworthy Future

Fri Feb 6 18:23:47 UTC 2026


Vagrant Cascadian pushed to branch master at Reproducible Builds / reproducible-presentations


Commits:
00ce0af9 by Vagrant Cascadian at 2026-02-06T10:22:01-08:00
WIP: Reproducible Builds: A Trustworthy Future

- - - - -


1 changed file:

- + proposed/2026-xx-rb-futures/rb-futures-script.org


Changes:

=====================================
proposed/2026-xx-rb-futures/rb-futures-script.org
=====================================
@@ -0,0 +1,317 @@
+* Reproducible Builds: A Trustworthy Future
+
+Hello! My name is Vagrant Cascadian, and this is
+
+Reproducible Builds: A Trustworthy Future
+
+This will be a bit of a whirlwind tour introducing Reproducible Builds
+and end with a focus on the Nice Things that we can all have once
+Reproducible Builds become the norm.
+
+* What is Reproducible builds
+
+Very roughly it is about building software or other digital artifacts,
+and getting the same results.
+
+More specifically, it is about building artifacts that are
+
+* Bit for bit identical
+
+Weather that is and individual piece of...
+
+* software
+
+* operating system image
+
+documentation, such as
+
+* PDF
+
+or
+
+* Epub
+
+or really
+
+* any artifact
+
+I will stress again the importance of...
+
+* Bit for bit identical
+
+Not just similar, or even semantically equivalent.
+
+This is because bit-identical things are easy to...
+
+* Verify
+
+with checksums.
+
+Other methods of verification, such as testing the behavior of a
+software artifact, can only test what you have thought to test in
+advance, and may have bugs in your test processes.
+
+Strong checksums against objects that are supposed to be identical is
+the simplest way to remove doubt.
+
+Fundamentally, Reproducible Builds is about building a strong
+
+* Verification
+
+path linking
+
+* Artifacts
+
+to their originating
+
+* Source Code
+
+* sources + toolchains + processes = artifacts
+
+So,
+
+* What
+
+is needed for a Reproducible build?
+
+* Document
+
+the build environment.
+
+most notably, the software versions (and ideally checksums) of all the
+tools used to produce your artifacts. You might get some or all of the
+necessary information in a Software Bill of Materials, a.k.a. SBOM,
+although some of the SBOM specifications may allow for obfuscated
+details. Caveat Emptor!
+
+Then you might typically Perform a
+
+* Build
+
+could be as simple as a classic configure, make, make install, or
+could be building a using package-specific tooling such as those used
+to build .deb or .rpm, archlinux or other package formats, Whatever
+your typical build process is that produces your artifacts.
+
+Now you should have your artifact, so, record the...
+
+* Results
+
+of your build, such as the checksums of all your produced artifacts.
+
+Now, try to
+
+* Build again
+
+from another computer
+
+ideally, somewhere a little
+
+* Different
+
+such as another computer, maybe running an older or newer kernel
+version, maybe with the clock set in the distant future or past, but
+with ostensibly the same build environment toolchains, et cetera.
+
+You should get a second set of artifacts...
+
+Now you can ask the question Do the
+
+* Checksums match?
+
+If they don't, investigate why...
+
+The most commonly occurring and simple to understand problem is
+
+* Timestamps
+
+and
+
+* Dates
+
+and even 
+
+* Timezones
+
+Which is to say all different forms of
+
+* Timestamps
+
+Find places in your code that might be embedding timestamps!
+
+The best timestamp is no timestamp!
+
+There are of course many, many
+
+* Other problems
+
+Like any software debugging, you test the issue, iterate through
+attempted ways to resolve it, and keep trying until you resolve the
+issues.
+
+I will point you at our documentation at
+
+* https://reproducible-builds.org/docs
+
+Which lists different kinds of problems in the Managing Variance
+section.
+
+And while you're there, I just noticed the Reproducibility Quickstart
+Guide
+
+* https://reproducible-builds.org/docs/getting-started
+
+Which kinds of spells out how to go about leveraging all this
+documentation.
+
+But remember, nothing is ever perfect, and once you made something
+build reproducibly, you need to check the results in a
+
+* Systematic
+
+Manner over time.
+
+Obviously, you would not want to be verifying all your packages by
+hand all the time!
+
+So be sure to set up Reproducible Builds tests for any Continuos
+Integration, Continuous Deployment and Quality Control systems you
+have in place already! You are probably already doing at least one
+build, why not two?
+
+With that out of the way, I want to travel a bit into a possible
+
+* Future
+
+No! not
+
+* Timestamps
+
+but do get rid of timestamps in your projects!
+
+I mean the
+
+* Future
+
+in which Reproducible Builds becomes a normal, standard practice, that
+can generally be relied on. Where unreproducibility is a surprise to
+be investigated.
+
+What sort of things are different about this future?
+
+One of the first things that leaps to my mind is how much easier
+
+* Decentralized
+
+sharing of artifacts will be.
+
+When independent third parties can collaboratively confirm each
+other's artifacts, you can distribute artifacts peer to peer, while
+having an independent vetting process that those artifacts are the
+correct, legitimate artifacts.
+
+Part of that future is already here, with the
+
+* Guix
+
+package manager, you can download signatures from a trusted source,
+and download the bulk of the contents from an untrusted source,
+verifying the signature independently, simply by specifying an
+additional location to download from.
+
+But really, I want to move beyond signatures and
+
+* Trust
+
+... to some extent, because currently in Guix, you still trust all
+signing parties equally, which is a weakest link in the chain
+scenario.  Any one of the trusted parties could be compromised and
+introduce malicious content.
+
+But because Guix packages are by and large bit-for-bit Reproducible,
+you can 
+
+* Verify
+
+the results of multiple independent parties.
+
+Being able to verify the results with Reproducible Builds, rather than
+simply trusting the signatures, moves beyond simple trust and into
+
+* Trustworthy
+
+distribution of artifacts.
+
+So do we want a
+
+* Trustworthy Future
+
+Well, at least in Guix, any single signer is valid. To move towards a
+Trustworthy Future, we would need some more sophisticated policies; a
+specific number of trusted builds augmented by several less trusted
+builds? Two parties that could never agree on anything else actually
+agreeing on the checksums of your builds?
+
+Obviously, for this hypothetical future, we would also want these
+sorts of mechanisms available beyond Guix as well! While Guix has
+parts of the implementation already, the fundamental concept is not
+unique to Guix!
+
+... But what are other example applications of Reproducible Builds in
+this trustworthy future?
+
+Can help with detection of unreliable
+
+* Hardware
+
+If 12 other build machines are all agreeing on build results, but one
+consistently produces different results, you might want to check out
+the memory, cpu or disk health.
+
+Or, maybe that situation would lead to an investigation of
+
+* Compromised
+
+build machines. With distributed verification, the incentives to
+attack an individual build machine or build network are significantly
+reduced if you readily detect differences in other independently
+managed build machines or networks.
+
+Similarly, It also can lessen the impact of social
+
+* Coercion
+
+as the independent build networks will quickly discover something is
+wrong.
+
+A whole additional angle is that, if you have reproducible builds, you
+can readily verify the
+
+* Licensing
+
+audits and compliance of your projects, as it requires you do
+demonstrate what is actually used to perform the build, and you can
+prove that no hidden dependencies work their way into the project.
+
+Reproducible Builds is also great for rooting out
+
+* Bugs
+
+in your builds. One I see fairly often is memory addresses or
+commandline program errors getting embedded in your documentation.
+
+Which improves the
+
+* Quality
+
+of the build.
+
+By reducing the pointless churn of differences between
+your builds
+
+* Refactoring
+
+code can make it easier to spot the intentional differences you expect
+when updating code, rather than arbitrary differences for no apparent
+reason.
+



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/commit/00ce0af90a514cf27d9848e5396d34088ccb7c20

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/commit/00ce0af90a514cf27d9848e5396d34088ccb7c20
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20260206/3ddd43d6/attachment.htm>
