[reproducible-website] 01/01: rws3: liberate notes about 1st bootstrapping session
Holger Levsen
holger at layer-acht.org
Wed Dec 20 12:41:42 UTC 2017
This is an automated email from the git hooks/post-receive script.
holger pushed a commit to branch master
in repository reproducible-website.
commit 7df4ba0238d2b6bfc8f265aa9c74c9f35fc9603f
Author: Holger Levsen <holger at layer-acht.org>
Date: Wed Dec 20 12:41:31 2017 +0000
rws3: liberate notes about 1st bootstrapping session
Signed-off-by: Holger Levsen <holger at layer-acht.org>
---
.../ReproducibleSummitIIIEventDocumentation.md | 118 +--------------------
_events/berlin2017/agenda.md | 7 +-
_events/berlin2017/bootstrapping.md | 66 ++++++++++++
3 files changed, 68 insertions(+), 123 deletions(-)
diff --git a/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md b/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md
index fed2e2d..d0d6ba3 100644
--- a/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md
+++ b/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md
@@ -29,8 +29,7 @@ Working sessions I
Working sessions II
* [How to fix the current issues with BUILD_PATH_PREFIX_MAP]({{ "/events/berlin2017/buildpathprefixmap/" | prepend: site.baseurl }})
-
-:::[[#RefHeadingToc4094118152727|How bootstrapping relates to reproducible builds and how to improve it]]
+* [How bootstrapping relates to reproducible builds and how to improve it]({{ "/events/berlin2017/bootstrapping/" | prepend: site.baseurl }})
:::[[#RefHeadingToc4096118152727|What documentation is still to be created for developers who are new to reproducible builds?]]
@@ -99,121 +98,6 @@ Working sessions VII
=== Working sessions II ===
-==== {{anchor|RefHeadingToc4094118152727}} How bootstrapping relates to reproducible builds and how to improve it ====
-
-
-
-bootstrappable.org
-
-
-bootstrappable builds
-
-
-open questions:
-
-What is the relationship to reproducibility?
-
-Why should we care?
-
-We need to trust binaries used during build. If build binaries are not trustworthy, this makes build results less trustworthy.
-
-
-#If we have a exe at the top and a lib it depends on, do we call the exe reproducible even if the lib is not reproducible?
-
-
-is trust binary / black&white? no...
-
-
-overlap:
-
-build as much from source to need less trust in binaries, and to be able to read/review the source
-
-increase trust in the software we build
-
-trust gets added with every way you can build a software from source
-
-
-diff: reproducible builds: done when 100% of packages are building reproducibly
-
-bootstrappable: (C-part) done when one can take any C-compiler and compile the production C-compiler and with that get bit-identical binaries of anything
-
-
-Requirement for doing bootstrappable builds:
-
-A "seed set" of bootstrap binaries has to be declared by a project (e.g. see f-droid below or a binary with a specific checksum), must not be implicit (e.g. previous version of myself)
-
-For build use a limited build environment containing only those binaries and nothing more.
-
-
-large complex source can still be hard to read, understand, verify => reduce amount of trusted software
-
-backdoors in built source code are out of scope of bootstrappable builds
-
-
-
-
-Is it a software freedom problem? maybe, maybe not
-
-long chains of A->B->C may bitrot and break over time, give less trust than A->C ; but we have archives, and containers
-
-obsolete hardware needs to be emulated and the emulator becomes part of the binaries we need to trust.
-
-
-Have build scripts that are fully specified about versions of compilers, etc to use in a boostrap-chain.
-
-
-Note: Trust is not transitive (unlike a=b=c meaning a=c) so if the sister of a friend knows someone who verified this it is not as much trust as "I verified this". Possibly also beacause trusting someone very much translates to a factor of 0.9x thus for every level of indirection you lose some trust.
-
-
-f-droid: using debian binaries as much as possible because they are built from source and thus more trustworthy.
-
-guix: build archive with checksums of everything with 218MB bootstrap binaries
-
-openSUSE: FIXME link to Ring-0
-
-
-
-
-Goal: come up with very small set of auditable binaries+sources
-
-https://gitlab.com/janneke/mes is close
-
-https://savannah.nongnu.org/projects/stage0
-
-Goal: need zero trust in the seed set of binaries - cannot be fully reached, but we can get to very small (maybe infinitessimal) values of trust needed.
-
-
-How to distinguish trusted bootstrap binaries from other binaries?
-
-
-
-
-tools/compilers that depend on themselves:
-
-gradle
-
-ghc(Haskell)
-
-rust
-
-maven
-
-
-
-
-
-
-identify important next steps:
-
-collect list of bootstrappable and non-bootstrappable tools
-
-convert notes to proper doc
-
-identify high-importance targets to achive bootstrappability
-
-more to be discussed
-
-
==== {{anchor|RefHeadingToc4096118152727}} What documentation is still to be created for developers who are new to reproducible builds? ====
diff --git a/_events/berlin2017/agenda.md b/_events/berlin2017/agenda.md
index 99da57a..66b24db 100644
--- a/_events/berlin2017/agenda.md
+++ b/_events/berlin2017/agenda.md
@@ -36,17 +36,12 @@ Participants generated a list of topics and questions that they wanted to discus
15:05 Break
-
15: 25 Working sessions II
* [How to fix the current issues with BUILD_PATH_PREFIX_MAP]({{ "/events/berlin2017/buildpathprefixmap/" | prepend: site.baseurl }}) – Ximin
-* How bootstrapping relates to reproducible builds and how to improve it – Ricardo
+* [How bootstrapping relates to reproducible builds and how to improve it]({{ "/events/berlin2017/bootstrapping/" | prepend: site.baseurl }}) – Ricardo
* What documentation is still to be created for developers who are new to reproducible builds? – Holger
-
-
-
-
16.45 Closing plenary
The meeting day ended with an invitation to all participants to share their goals and wishes for the following days, and words of gratitude for a productive start of the Summit.
diff --git a/_events/berlin2017/bootstrapping.md b/_events/berlin2017/bootstrapping.md
new file mode 100644
index 0000000..6463a35
--- /dev/null
+++ b/_events/berlin2017/bootstrapping.md
@@ -0,0 +1,66 @@
+---
+layout: event_detail
+title: How bootstrapping relates to reproducible builds and how to improve it
+event: berlin2017
+order: 80
+permalink: /events/berlin2017/bootstrapping/
+---
+
+* https://bootstrappable.org
+* bootstrappable builds
+
+open questions:
+
+* What is the relationship to reproducibility?
+* Why should we care?
+* We need to trust binaries used during build. If build binaries are not trustworthy, this makes build results less trustworthy.
+* If we have a exe at the top and a lib it depends on, do we call the exe reproducible even if the lib is not reproducible?
+* is trust binary / black&white? no...
+
+overlap:
+
+* build as much from source to need less trust in binaries, and to be able to read/review the source
+* increase trust in the software we build
+* trust gets added with every way you can build a software from source
+* diff: reproducible builds: done when 100% of packages are building reproducibly
+* bootstrappable: (C-part) done when one can take any C-compiler and compile the production C-compiler and with that get bit-identical binaries of anything
+
+Requirement for doing bootstrappable builds:
+
+* A "seed set" of bootstrap binaries has to be declared by a project (e.g. see f-droid below or a binary with a specific checksum), must not be implicit (e.g. previous version of myself)
+* For build use a limited build environment containing only those binaries and nothing more.
+* large complex source can still be hard to read, understand, verify => reduce amount of trusted software
+backdoors in built source code are out of scope of bootstrappable builds
+* Is it a software freedom problem? maybe, maybe not
+* long chains of A->B->C may bitrot and break over time, give less trust than A->C ; but we have archives, and containers
+* obsolete hardware needs to be emulated and the emulator becomes part of the binaries we need to trust.
+* Have build scripts that are fully specified about versions of compilers, etc to use in a boostrap-chain.
+
+Note: Trust is not transitive (unlike a=b=c meaning a=c) so if the sister of a friend knows someone who verified this it is not as much trust as "I verified this". Possibly also beacause trusting someone very much translates to a factor of 0.9x thus for every level of indirection you lose some trust.
+
+f-droid: using debian binaries as much as possible because they are built from source and thus more trustworthy.
+
+guix: build archive with checksums of everything with 218MB bootstrap binaries
+
+openSUSE: FIXME link to Ring-0
+
+Goal: come up with very small set of auditable binaries+sources
+
+* https://gitlab.com/janneke/mes is close
+* https://savannah.nongnu.org/projects/stage0
+
+Goal: need zero trust in the seed set of binaries - cannot be fully reached, but we can get to very small (maybe infinitessimal) values of trust needed.
+
+How to distinguish trusted bootstrap binaries from other binaries?
+tools/compilers that depend on themselves:
+* gradle
+* ghc(Haskell)
+* rust
+* maven
+
+identify important next steps:
+* collect list of bootstrappable and non-bootstrappable tools
+* convert notes to proper doc
+* identify high-importance targets to achive bootstrappability
+* more to be discussed
+
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git
More information about the Reproducible-commits
mailing list