50/66: programming-2022: Address comments from Reviewer A.

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit d9ece1007841cfd8b5a571e305a219f613f751c4
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Wed Apr 13 08:09:52 2022 +0200

    programming-2022: Address comments from Reviewer A.
    
    * doc/programming-2022/supply-chain.skb: Tweak.
    * doc/programming-2022/security.sbib (courtes2016:authentication): New
    entry.
---
 doc/programming-2022/security.sbib    |  7 +++
 doc/programming-2022/supply-chain.skb | 85 ++++++++++++++++++++++++++---------
 2 files changed, 70 insertions(+), 22 deletions(-)

diff --git a/doc/programming-2022/security.sbib 
b/doc/programming-2022/security.sbib
index f957794..12ae6bf 100644
--- a/doc/programming-2022/security.sbib
+++ b/doc/programming-2022/security.sbib
@@ -291,6 +291,13 @@ Thayer")
   (year "2021")
   (url "https://github.com/cryptidtech/git-cryptography-protocol";))
 
+(misc courtes2016:authentication
+  (author "Ludovic Courtès et al.")
+  (year "2016")
+  (month "May")
+  (url "https://issues.guix.gnu.org/22883";)
+  (title "Trustable “guix pull”"))
+
 (misc devos2021:diverted
   (author "Maxime Devos")
   (year "2021")
diff --git a/doc/programming-2022/supply-chain.skb 
b/doc/programming-2022/supply-chain.skb
index 2e37095..4409b14 100644
--- a/doc/programming-2022/supply-chain.skb
+++ b/doc/programming-2022/supply-chain.skb
@@ -202,9 +202,11 @@ local copy of the Guix source code.  Prior work on secure 
software
 updates focuses on systems very different from Guix—systems such as
 Debian, Fedora, or PyPI where updating consists in fetching metadata
 about the latest binary artifacts available—and is largely inapplicable in
-the context of Guix.  Deployment tools that more closely resemble Guix,
-from Nix to Portage, either lack secure update mechanisms or suffer from
-shortcomings.])
+the context of Guix.  By contrast, the main threats for Guix are attacks
+on its ,(emph [source code repository]), which could lead users to run
+inauthentic code or to downgrade their system.  Deployment tools that
+more closely resemble Guix, from Nix to Portage, either lack secure
+update mechanisms or suffer from shortcomings.])
      (p [Our main contribution is a model and tool to authenticate new
 Git revisions.  We further show how, building on Git semantics, we build
 protections against downgrade attacks and related threats.  We explain
@@ -252,7 +254,9 @@ automated tools (…) to maintain trusted source code supply 
chains” ,(ref
 current practices and tools is unquestioned.])
       
       (p [GNU Guix is a set of software deployment tools and a
-standalone GNU/Linux distribution.  It includes a package manager with a
+standalone GNU/Linux distribution whose development started in 2012
+,(ref :bib 'courtes2013:functional).
+It includes a package manager with a
 command-line interface similar to that of Debian’s apt or Fedora’s yum,
 allowing users to search for software packages, to install them, and to
 upgrade them.  Unlike apt, yum, and many popular package managers, Guix
@@ -277,7 +281,10 @@ inapplicable in the context of Guix.  Deployment tools 
that more closely
 resemble Guix, from Nix to Portage and BSD Ports ,(ref :bib
 '(dolstra2004:nix brew2022:github condaforge2022:web
 freebsd2022:handbook pkgsrc2022:guide gentoo2022:portage-security)),
-either lack secure update mechanisms or suffer from shortcomings.])
+either lack secure update mechanisms or suffer from shortcomings.
+Git itself allows individual commits and tags to be authenticated but
+offers no way to authenticate a complete checkout—making sure ,(emph
+[each]) commit was made by an ,(emph [authorized]) party.])
 
 ;;       (p [More generally, contrary to recent work on supply chain
 ;; security that revolves around ,(emph [attestation]) of the various
@@ -340,7 +347,9 @@ software engineering ,(ref :bib 
'hinsen2020:staged-computation).])
 requirement is that the system runs the Linux kernel—be it Android or a
 GNU/Linux distribution.  Guix packages stand alone: they provide all the
 user-land software they need, down to the C library; this guarantees
-they behave the same on any system.])
+they behave the same on any system, as evidenced by more than twenty
+years of experience with the functional deployment model ,(ref :bib
+'(dolstra2004:nix courtes2013:functional)).])
 
         (p [There are other tools beyond the “package manager”
 interface.  The ,(tt [guix shell]) command, for example, creates a
@@ -427,12 +436,19 @@ enable users and developers to verify that a binary 
matches a given
 piece of source code: anyone can rebuild the package and ensure they
 obtain the same binary, bit for bit.  The explicit and unambiguous
 mapping from source to binary that the functional deployment model
-provides makes verification clear and easy.  For example, the command
+provides makes verification clear and easy.])
+
+        (p [For example, the command
 ,(tt [guix build --check hello]) rebuilds the ,(tt [hello]) package
 locally and prints an error if the build result differs from that
 already available.  Likewise, ,(tt [guix challenge hello]) compares
 binaries of the ,(tt [hello]) package available locally with those
-provided by one or several substitute servers.]))
+provided by one or several substitute servers.  These two commands allow
+users and developers to find about binaries that might have been
+tampered with.  For packagers, they are more commonly a way to find out
+about non-deterministic build processes—e.g., build processes that
+include timestamps or random seeds in their output, or that depend on
+hardware details.]))
         
       (section :title [Bootstrappable Builds]
 
@@ -477,7 +493,7 @@ small interpreter of the Scheme language written in C, 
capable enough to
 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
+C++.  That, coupled with other
 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)).
@@ -659,7 +675,9 @@ authorizations.])
     (name "charlie"))))])))
 
       (figure
-        :legend [Graph of commits and the associated authorizations.]
+        :legend [Graph of commits and the associated authorizations
+        (commit ,(it [A]) is the parent of commit ,(it [B]), commit
+        ,(it [B]) is the parent of ,(it [C]) and ,(it [E]), and so on).]
         :ident "fig-commits"
         (image :file "images/commit-graph.pdf"
            :width 0.7))
@@ -708,8 +726,10 @@ Revocation is similar: any authorized committer can remove 
entries from
 committer can remove their former key and add their new key in a single
 commit, signed by the former key.  If a developer’s key is compromised,
 for instance because their laptop was stolen, they can notify other
-committers so they immediately remove the key, thereby preventing it
-from being used to push new commits.])
+committers so they quickly remove the key, thereby preventing it
+from being used to push new commits; the Git log provides an undeniable
+audit trail when looking for commits that might have been pushed by an
+attacker who gained access to the key.])
 
       (p [The authorization invariant satisfies the needs of the Guix
 project.  It has one downside: it does not play well with the
@@ -717,7 +737,10 @@ pull-request-style workflow popularized by some source 
code hosting
 platforms.  Indeed, merging the branch of a contributor not listed in ,(tt
 [.guix-authorizations]) would break the authorization invariant, unless
 the committer who accepts the changes signs them, which involves
-rewriting the commit history of the branch that was submitted.  It is a
+rewriting the commit history of the branch that was submitted.  Doing
+this is possible but it requires the committer to perform this operation
+on their machine, as opposed to delegating it to the Web server by
+clicking on the “merge” button.  It is a
 good tradeoff for Guix where the contribution workflow relies on patches
 sent by email to a patch tracker, and where commits are signed by the
 committer rather than the original author, but it may be less suitable
@@ -850,7 +873,7 @@ from ,(it [F]) to ,(it [A]) or from ,(it [D]) to ,(it [E]) 
is not.])
       (p [Doing a non-fast-forward update would mean that the user is
 deploying an older version of the Guix currently used, or deploying an
 unrelated version from another branch.  In both cases, the user is at
-risk of ending up installing older, vulnerable software.  By default
+risk of ending up installing older, vulnerable packages.  By default
 ,(tt [guix pull]) errors out on non-fast-forward updates, thereby
 protecting from roll-backs.  Users who understand the risks can override
 that by passing ,(tt [--allow-downgrades]).])
@@ -1055,10 +1078,12 @@ context; what matters is whether the authorization 
invariant holds.])
         (p [On a recent x86_64 laptop (Intel i7 CPU at 2.6 GHz with
 data stored on a solid state device, SSD), our code authenticates
 between 600 and 700 commits per second.  There are currently between
-1,000 and 2,000 commits per month on average, so someone running ,(tt
-[guix pull]) once per month experiences a 2–3 second delay due to
-authentication.  This does not appear to be detrimental to the user
-experience.])
+1,000 and 2,000 commits per month on average (by comparison, the Nixpkgs
+distribution peaks at about 4,000 commits per month and the Linux
+kernel, one of the most active free software projects, reaches about
+6,000 commits per month).  Someone running ,(tt [guix pull]) once per
+month experiences a 2–3 second delay due to authentication.  This does
+not appear to be detrimental to the user experience.])
 
         (p [Another performance aspect has to do with Git repository
 handling.  The mechanisms we devised for commit authentication and
@@ -1118,7 +1143,16 @@ functionality in Git proper.]))
         (p [Channel authentication as described above has been deployed
 and used in production in Guix for more than a year, since June 2020.
 This has given us an informal but large-scale, “real-world” evaluation
-of this work.  When authentication support was integrated in production code,
+of this work.  It corresponds, today, to more than 32,000 commits that
+respect the authorization invariant.  The set of authorized developer
+keys in Guix changed a dozen times in that time frame.  The public
+discussion and review process among developers for the design and
+implementation of this mechanism ,(ref :bib 'courtes2016:authentication)
+helped improve it, eventually leading to a proposal to address a
+limitation of downgrade prevention ,(ref :bib 'devos2021:diverted) and a
+minor bug fix.])
+
+        (p [When authentication support was integrated in production code,
 users who ran ,(tt [guix pull]) transparently obtained the new
 code, and all subsequent invocations of ,(tt [guix pull]) performed code
 authentication and downgrade prevention.  In almost two years, there was one
@@ -1160,12 +1194,19 @@ on by server administrators.  The service periodically 
pulls and
 reconfigures the system.  With the guarantees Guix provides, the worst
 that can happen is that an upgrade does not take place.])
         
-        (p [Since it became available, authors of Guix channels have
-been adopting authentication support without hassle.  Outside Guix, generalized
+        (p [Since it became available, authors of Guix channels quickly
+adopted authentication support.  These people were
+typically already familiar with OpenPGP and signed commits;
+understanding the authorization model and coming up with a ,(tt
+[.guix-authorizations]) file was not a barrier to them.
+Outside Guix, generalized
 authentication support offered by ,(tt [guix git authenticate]) has seen
 use in a few repositories.  We have yet to see
 broader adoption but we reckon that simplifying the interface may be a
-precondition, as explained above.])))
+precondition, as explained above.  At a more fundamental level, ,(emph
+[explaining]) that no, signed commits and “verified” tags on a Web user
+interface (see below) are not enough to authenticate Git checkouts is
+arguably a prerequisite before we can advocate for a solution.])))
       
    (chapter :title [Related Work]
       :ident "related"