40/66: programming-2022: Tweak.

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit 0dfe6a80ffe8c5c2960bb6cd7cb75e98047c0462
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Sun Jan 30 15:19:03 2022 +0100

    programming-2022: Tweak.
    
    * doc/programming-2022/images/guix-package-workflow.tex: Add source tarball.
    * doc/programming-2022/supply-chain.skb: Add author biography.
    (Bootstrapped Builds): Mention TinyCC & co.
    (Rationale): Mention cryptographic hash of the source.
    (Related Work): Add headings.
---
 .../images/guix-package-workflow.tex               |  6 ++++
 doc/programming-2022/supply-chain.skb              | 41 +++++++++++++++-------
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/doc/programming-2022/images/guix-package-workflow.tex 
b/doc/programming-2022/images/guix-package-workflow.tex
index e214e50..8454963 100644
--- a/doc/programming-2022/images/guix-package-workflow.tex
+++ b/doc/programming-2022/images/guix-package-workflow.tex
@@ -15,6 +15,10 @@
                         drop shadow={opacity=0.5}
                       }]
     \matrix[row sep=1.4cm, column sep=0.4cm] {
+      \node(source)[box]{\texttt{http://\textrm{...}/Python-3.9.6.tar.gz}};
+      & &
+      \\
+
       \node(def)[box]{\texttt{(define python (package \textrm{...}))}};
       & & \node(user)[server]{user};
       \\
@@ -26,6 +30,8 @@
       \\
     };
 
+    \path[->, very thick, draw=guixblue2]
+      (source) edge node[left]{download} node[right]{hash} (def);
     \path[->, very thick, draw=guixblue2]
       (def) edge node[left]{test} (build);
     \path[->, very thick, draw=guixblue2]
diff --git a/doc/programming-2022/supply-chain.skb 
b/doc/programming-2022/supply-chain.skb
index fd36d75..677fcdd 100644
--- a/doc/programming-2022/supply-chain.skb
+++ b/doc/programming-2022/supply-chain.skb
@@ -154,7 +154,10 @@
    :author (list (author :name "Ludovic Courtès"
                    :affiliation "Inria"
                    :email "ludovic.courtes@inria.fr"
-                   :address (list "Bordeaux, France")))
+                   :address [works as a research engineer at Inria,
+France.  He has been contributing to the development of GNU Guix since
+its inception in 2012 and works on its use in support of reproducible
+research workflows.]))
 
    (!latex "\\paperdetails{perspective=engineering,
 area={Security programming}, license=cc-by-sa}\n")
@@ -415,6 +418,7 @@ visible to the build process.  This method, inherited from 
Nix ,(ref
 (RPCs) to a build daemon, which spawns build processes in isolated
 environments on their behalf and stores the build result in ,(tt
 [/gnu/store]).])
+
         (p [Build isolation, in turn, helps achieve bit-for-bit
 ,(emph [reproducible builds]), which are critical from a security
 standpoint ,(ref :bib 'lamb2021:reproducible).  Reproducible builds
@@ -469,7 +473,10 @@ this forty-year-old problem at its root: by ensuring no 
opaque binaries
 appear at the bottom of the package dependency graph—no less ,(ref :bib
 'janneke:mes-web).  To that end, Nieuwenhuizen developed GNU Mes, a
 small interpreter of the Scheme language written in C, capable enough to
-run MesCC, a non-optimizing C compiler.  That, coupled with other heroic
+run MesCC, a non-optimizing C compiler.  MesCC is then used to build
+TinyCC, a more sophisticated C compiler written in C, in turn used to
+build an old version of GCC, until we get to the modern GCC, written in
+C++.  That, coupled with other heroic
 efforts, led to a drastic reduction of the size of the opaque binaries
 at the root of the Guix package graph, well below what had been achieved
 so far ,(ref :bib '(janneke2020:bootstrap courant2022:ocamlboot)).
@@ -510,7 +517,8 @@ asset to be protected are binaries themselves ,(ref :bib
 question has to be approached from a different angle.])
 
       (figure :legend [Supplying software with Guix: developers (left)
-write package definitions, test them, and publish them in the Git
+write package definitions that contain a cryptographic hash of the
+source code, test them, and publish them in the Git
 repository; users (right) update their copy from Git using ,(tt [guix
 pull]) and either fetch binaries for the packages they need or build
 them locally.]
@@ -520,7 +528,11 @@ them locally.]
                    get-string-all)))
 
       (p [Guix consists of source code for the tools as well as package
-definitions that make up the GNU/Linux distribution.  All this code is
+definitions that make up the GNU/Linux distribution.  Package
+definitions contain the URL and cryptographic hash of their source code;
+it is up to package developers writing those definitions to authenticate
+upstream’s source code, for instance by verifying OpenPGP signatures.
+All this code is
 maintained under version control in a Git repository.
 To update Guix
 and its package collection, users run ,(tt [guix pull])—the equivalent
@@ -615,8 +627,7 @@ which the developer was officially an authorized 
committer.])
      
 The ,(tt [.guix-authorizations]) format is a Lisp-style s-expression,
 as shown in ,(numref :text [Figure] :ident
-"fig-guix-authorizations").  Besides being a natural choice for Guix,
-which is implemented in Scheme, a language of the Lisp family, such a
+"fig-guix-authorizations").  Such a
 structured format leaves room for extensions, such as per-file
 authorizations.])
 
@@ -714,7 +725,7 @@ authorization invariant?])
         :legend [The introductory commit in a commit graph.]
         :ident "fig-commit-graph-intro"
         (image :file "images/commit-graph-intro.pdf"
-           :width 0.7))
+           :width 0.6))
 
       (p [We solve this bootstrapping issue by defining ,(emph [channel 
introductions]).
 Previously, one would identify a channel solely by its URL.  Now, when
@@ -1155,7 +1166,8 @@ general context; recent work also looks into Git 
authentication and
 related issues.  This section attempts to summarize how Guix relates to
 similar work that we are aware of in these two areas.])
       
-      (p [The Update Framework ,(ref :bib 'samuel2010:survivable) (TUF)
+      (p [,(bold [Package manager updates.])
+The Update Framework ,(ref :bib 'samuel2010:survivable) (TUF)
 is a reference for secure update systems, with a well-structured
 specification ,(ref :bib 'cappos2020:tuf-spec) and a number of
 implementations.  Many of its goals are shared by Guix.  Among the
@@ -1191,7 +1203,8 @@ committer can touch any file; the model and the ,(tt
 [.guix-authorizations]) format leave room for per-file authorizations,
 which could be a way to define fine-grain roles in this context.])
 
-      (p [The Nix package manager is “source-based” like Guix and
+      (p [,(bold [Updates for source-based distributions.])
+The Nix package manager is “source-based” like Guix and
 distributes its package definitions as a Git repository.  It does not
 currently implement Git checkout authentication and secure updates.  A
 proposal requiring committers to sign commits was rejected, mainly for
@@ -1235,7 +1248,8 @@ containing “build recipe”.  To date, it appears that ,(tt 
[opam update])
 itself does not authenticate repositories though; it is up to users and
 developers to run Conex.])
       
-      (p [The in-toto framework ,(ref :bib 'torresarias2019:intoto) can be 
thought of as a
+      (p [,(bold [Supply chain integrity.])
+The in-toto framework ,(ref :bib 'torresarias2019:intoto) can be thought of as 
a
 generalization of TUF; it aims at ensuring the integrity of complete
 software supply chains, taking into accounts the different steps that
 comprise software supply chains in widespread use such as Debian’s.  In
@@ -1260,7 +1274,8 @@ verification statuses.]
         :ident "fig-github-verification"
         (image :file "images/github-verification-statuses.png"))
 
-      (p [While signed Git commits (and tags) are becoming more common
+      (p [,(bold [Git authentication.])
+While signed Git commits (and tags) are becoming more common
 and generally seen as good practice, we are not aware of other tools or
 protocols to support off-line Git checkout authentication.  Recently,
 as illustrated in ,(numref :ident "fig-github-verification" :text [Figure]),
@@ -1271,7 +1286,7 @@ may give a false sense of security
 ,(ref :bib '(github2021:verify-commits gitlab2021:verify-commits)).
 This mechanism depends on out-of-band data (keys associated with user
 accounts) and does not permit off-line checks; it also lacks a notion of
-authorization.  Furthermore, commits made ,(it [via]) the web interface
+authorization.  Furthermore, commits made ,(it [via]) the Web interface
 are signed by the platform itself, which makes it a single point of
 trust of every hosted project.])
 
@@ -1284,7 +1299,7 @@ users to pull an older commit or an unrelated commit.  As 
written above,
 would fail to detect cases where metadata modification does not yield a
 rollback or teleport, yet gives users a different view than the intended
 one—for instance, a user is directed to an authentic but different
-branch rather than the intended one.  This potentially allows for ,(it
+branch rather than the intended one ,(ref :bib 'devos2021:diverted).  This 
potentially allows for ,(it
 [indefinite freeze attacks]), though these would likely be quickly
 detected.  The “secure push” operation and the associated ,(emph
 [reference state log]) (RSL) the authors propose would be an