Skip to content
GitLab
Commits (2)
Hide whitespace changes
Inline Side-by-side
2023-04-24-foss-north.se-R-B-the-first-10-years/index.html
View file @ 11c9aa35
<!doctype html>
<html lang="en">
<!--
TODO:
- hide slides which are too debian specific but might be useful later in a more debian specific talk.
- try not to assume knowledge about debian release processes.
- /docs/history
- refer to other talks:
- 2015 fosdem has a long list of issues
- thread model much better explained by lamby
- slide?: change my mind - or after certain statements (single apps r-b usefulness)
- slide?: bootstrapable.org - this is limited to software. reproducible hardware & free & reproducible firmware...
slide: but surely: the goal of this talk is
- to get you excited & involved &|| caring and thus supportive
- recap what we have done, celebrate 10y of awesomeness
- explain that 97% is a nice meaningless number, i mean
- explain what still needs doing & partly is done of cource etc pp
- so yeah, there's still a lot to be done after 100% which will make a UI obsolete
- think SBOM binary transparency merkel tree
- on a distro scale (say: "please do it with an r-b debian fork. hah, doesnt work because of the 97% only yet".)
slide: disclaimer: i'm a debian dd but i run tests for a lot of other projects, with more or less help/usage from them.
slide: r-b is now barely a teenie. I look forward to it being grown up, so in 8 years, I hope to be able to let it go.
slide: this talk is about my r-b story since 10y. r-b existed at least 30y ago.
slide: what is r-b (intro etc.)
slide: why? threat models
slide: supply chain attacks. SBOM. presidental directive.
slide: what does this mean for free software? unclear, but we do the technical groundwork & non black boxes *require* open source.
slide: but lets go back...
slide: gcc r-b in 199x
slide: mail from 1997
slide: bitcoin & torbrowser in 2012
slide: debconf13
slide: ccc talk 2013
slide: fosdem 2014
slide: camp 2015
slide: SOURCE_DATE_EPOCH 1.0 2015, 1.1 2017
slide" build path variation: 2023: don't do it. Bug#1034424: buildd.debian.org: Please use predictible build paths
(for Debian folks: no more build path variation in unstable)
slide: r-b summits, 5 so far, next to come.
slide: talks at debconfs
slide: funding: first LF, now an SFC project. I like the SFCs focus on freedom.
slide: 2017: debian-policy: should
slide: 2023 debian bullseye: will be explained in a bit :)
slide: recent mail from wireguard
slide: distro details:
slide: tails
slide: free- & netbsd
slide: fedora (show makro enabled thing)
slide: archlinux (mention: they are great. have rebuilders. pacman-bintrans a model for debian and everyone else.)
slide: f-droid
single apps reproducibililty not practical
slide: nix
slide: guix
slide: honorable mention: trisqel
slide: ubuntu, mint, rhel
slide: macos, windows, google android
slide: debian:
slide:
columns: stretch buster bullseye bookworm
rows: amd64 arm64 i386 armhf with percentages
slide: now: teh future!
slide: recap: we all support SOURCE_DATE_EPOCH
/docs/source-date-epoch/
slide: recap: .buildinfo files / SBOM
recorded or predictable/static buildpath
(for Debian folks: no more build path variation in unstable)
slide: SBOMs are nothing new, we know them since 2014 or so.
verified SBOMs are cool: = have been used to verify = reproduce a build
slide: trixie, forky & probably 2 more until 100% reproducible Debian stable.
100% reproducible is a politcal task, not technical.
slide: rebuilders (rebuild Debian on every point release? as in: publish those .buildinfo files as one tar archive maybe?)
slide: technically eventually "done"/doable, but practically?
slide: personally, i want to finish this. by 2030: no more unreproducible builds in Debian stable.
slide: we need you. *i* need you. :) we need each other.
slide: r-b, the only way you can be sure the binary you are running is the free software you think you are running.
or in SBOM speak: ... ("did you get what you bought?" :)
-->
<head>
<meta charset="utf-8">
<title>Reproducible Builds - the first ten years</title>
......@@ -226,7 +146,7 @@ slide: r-b, the only way you can be sure the binary you are running is the free
<section>
<p style="font-size: 120%"><em>
maybe the talk title should have been:<br> </em>my<em> first 10 years with reproducible builds...
maybe the talk title should have been:<br> <u>my</u> first 10 years with reproducible builds...
<span class="fragment">
<br>though this is not about my work.
......@@ -234,7 +154,12 @@ maybe the talk title should have been:<br> </em>my<em> first 10 years with repro
<span class="fragment">
<br>
Reproducible builds, like Free Software in general,
is a collective effort:
is a collective effort.
</span>
<span class="fragment">
<br>
Also the idea is much older than 10 years...
</span>
</em>
</p>
......@@ -417,8 +342,10 @@ maybe the talk title should have been:<br> </em>my<em> first 10 years with repro
<ol>
<li>Holger Levsen / holger@debian.org</li>
<li>Located in Hamburg, Germany</li>
<li>Debian user since 1995, contributing since 2001, Debian member since 2007</li>
<li>Working on Reproducible Builds since 2014</li>
<li>Debian user since 1995, contributing since 2001, Debian member since 2007. <span class="fragment">I ❤️ Debian.</span></li>
<li><span class="fragment">Working on Reproducible Builds since 2014,</span>
<span class="fragment">trying to make all ❤️ Free Software reproducible.</span></li>
</ol>
</section>
......@@ -436,7 +363,8 @@ maybe the talk title should have been:<br> </em>my<em> first 10 years with repro
<ul>
<li class="fragment">Who knows about Reproducible Builds, why and how?</li>
<li class="fragment">Who contribute(s|d) to Reproducible Builds?</li>
<li class="fragment">Who knew that Reproducible Builds are known for more than 10 years?</li>
<li class="fragment">Who knows that Reproducible Builds have been known for more than 10 years?</li>
<li class="fragment">Who knows about SBOM?</li>
</ul>
</section>
......@@ -472,9 +400,10 @@ maybe the talk title should have been:<br> </em>my<em> first 10 years with repro
<section data-background="images/fn-logo.png" data-background-size="12%" data-background-position="90% 10%">
<p>I'll mostly ignore <em>why</em> and <em>how to do such builds</em> today.</p>
<p class="fragment">I'll just mention that by now this has been widely understood as a problem:
<br><span style="font-size: 70%">https://www.whitehouse.gov/briefing-room/statements-releases/2021/06/08/...</span></li>
<p>I'll mostly ignore <em>why</em> and <em>how</em> to do such builds today.</p>
<p> <span class="fragment">By now this has been widely and largly understood: </span>
<br><span class="fragment" style="font-size: 100%">https://reproducible-builds.org/resources/<br>https://reproducible-builds.org/docs/</span></li>
<br><span class="fragment" style="font-size: 70%">https://www.whitehouse.gov/briefing-room/statements-releases/2021/06/08/...</span></li>
</section>
<section data-background-color="white">
......@@ -511,6 +440,7 @@ Arch Linux is 86.4% reproducible with 1701 bad and 10849 good packages.
<li class="fragment">Alpine: basic support</li>
<li class="fragment">FreeBSD/NetBSD/OpenBSD: basic support</li>
<li class="fragment">Fedora/Redhat/Ubuntu: not interested it seems</li>
<li class="fragment">though Fedora recently enabled r-b features via a makro</li>
</ul>
</section>
......@@ -685,25 +615,6 @@ Arch Linux is 86.4% reproducible with 1701 bad and 10849 good packages.
<section data-background="images/fn-logo.png" data-background-size="12%" data-background-position="90% 10%">
<h3>Then, since "Hamburg", something broke and we're at:</h3>
<ul>
<li>93.0% for bookworm/amd64</li>
<li>93.7% for bookworm/arm64</li>
<li>but why ???</li>
</ul>
</section>
<section data-background="images/fn-logo.png" data-background-size="12%" data-background-position="90% 10%">
<h3>why 93.x% for bookworm now?</h3>
<img src="images/stats_pkg_state.png">
</section>
<section data-background="images/fn-logo.png" data-background-size="12%" data-background-position="90% 10%">
<h3>why 93.x% for bookworm now?<br> because haskell FTBFS...</h3>
<img src="images/stats_meta_pkg_state_maint_pkg-haskell-maintainers.png">
</section>
<section data-background="images/fn-logo.png" data-background-size="12%" data-background-position="90% 10%">
<h3>CI versus rebuilds:</h3>
......@@ -898,9 +809,7 @@ Arch Linux is 86.4% reproducible with 1701 bad and 10849 good packages.
Thank you
<br><small>&hellip; and all the contributors out there!</small>
</h3>
<p class="fragment">Do you think reproducible builds should happen?<br> If so, please pick <em>one</em> of these bugs and help fixing.<br />We need your help.</p>
<p class="fragment">https://wiki.debian.org/ReproducibleBuilds</p>
<br>
<p class="fragment">Do you think reproducible builds should happen?<br> If so, please help.<br />We need your help.</p>
<p class="fragment"><em>I still haven't found what I'm looking for <br> but I'm confident we'll get there, eventually!</em></p>
<h3>
<small>Holger Levsen &lt;holger@debian.org&gt;<br>
......
2023-04-24-foss-north.se-R-B-the-first-10-years/todo 0 → 100644
View file @ 11c9aa35
TODO:
- link fedora makro
- link wiregard news
- include mail to which manoj replied
- include gcc 1990s news.
- slide about SBOM: not related to r-b but without r-b it's rather meaningless. "just a promise".
- /docs/history
- explain S_D_E
- explain predictable build pathes
- refer to other talks:
- 2015 fosdem has a long list of issues
- thread model much better explained by lamby
- slide?: change my mind - or after certain statements (single apps r-b usefulness)
- slide?: bootstrapable.org - this is limited to software. reproducible hardware & free & reproducible firmware...
- say thanks to sponsors, one has even been from Göteburg: mulvad
(mail them too)
slide: but surely: the goal of this talk is
- to get you excited & involved &|| caring and thus supportive
- recap what we have done, celebrate 10y of awesomeness
- explain that 97% is a nice meaningless number, i mean
- explain what still needs doing & partly is done of cource etc pp
- so yeah, there's still a lot to be done after 100% which will make a UI obsolete
- think SBOM binary transparency merkel tree
- on a distro scale (say: "please do it with an r-b debian fork. hah, doesnt work because of the 97% only yet".)
slide: r-b is now barely a teenie. I look forward to it being grown up, so in 8 years, I hope to be able to let it go.
slide: why? threat models
slide: supply chain attacks. SBOM. presidental directive.
slide: what does this mean for free software? unclear, but we do the technical groundwork & non black boxes *require* open source.
slide: but lets go back...
slide: gcc r-b in the 1990s, we learned in 2017
slide: mail from 1997
slide: bitcoin & torbrowser in 2012
slide: debconf13
slide: ccc talk 2013
slide: fosdem 2014
slide: camp 2015
slide: SOURCE_DATE_EPOCH 1.0 2015, 1.1 2017
slide" build path variation: 2023: don't do it. Bug#1034424: buildd.debian.org: Please use predictible build paths
(for Debian folks: no more build path variation in unstable)
slide: r-b summits, 5 so far, next to come.
slide: talks at debconfs
slide: funding: first LF, now an SFC project. I like the SFCs focus on freedom.
slide: 2017: debian-policy: should
slide: 2023 debian bullseye: will be explained in a bit :)
slide: recent mail from wireguard
slide: distro details:
slide: fedora (show makro enabled thing)
slide: archlinux (mention: they are great. have rebuilders. pacman-bintrans a model for debian and everyone else.)
slide: f-droid
single apps reproducibililty not practical
slide: nix
slide: guix
slide: honorable mention: trisqel
slide: ubuntu, mint, rhel
slide: macos, windows, google android
slide: debian:
slide:
columns: stretch buster bullseye bookworm
rows: amd64 arm64 i386 armhf with percentages
slide: recap: we all support SOURCE_DATE_EPOCH
/docs/source-date-epoch/
slide: recap: .buildinfo files / SBOM
recorded or predictable/static buildpath
(for Debian folks: no more build path variation in unstable)
slide: SBOMs are nothing new, we know them since 2014 or so.
verified SBOMs are cool: = have been used to verify = reproduce a build
slide: trixie, forky & probably 2 more until 100% reproducible Debian stable.
100% reproducible is a politcal task, not technical.
slide: rebuilders (rebuild Debian on every point release? as in: publish those .buildinfo files as one tar archive maybe?)
slide: technically eventually "done"/doable, but practically?
slide: personally, i want to finish this. by 2030: no more unreproducible builds in Debian stable.
slide: r-b, the only way you can be sure the binary you are running is the free software you think you are running.
or in SBOM speak: ... ("did you get what you bought?" :)