34/66: programming-2022: Clarify bits.

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit 314a089d80895b18d4fcb0c50fdbb2dcaca1e666
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Fri Jan 21 17:35:07 2022 +0100

    programming-2022: Clarify bits.
    
    * doc/programming-2022/security.sbib: Tweak.
    * doc/programming-2022/supply-chain.skb (Rationale): Add summarizing
    paragraph at the end.
    (Performance): Add note on the first-time cost of running 'guix pull'.
    (Experience): Rename to...
    (Evaluation): ... this.
---
 doc/programming-2022/security.sbib    |  2 +
 doc/programming-2022/supply-chain.skb | 79 ++++++++++++++++++++++++-----------
 2 files changed, 56 insertions(+), 25 deletions(-)

diff --git a/doc/programming-2022/security.sbib 
b/doc/programming-2022/security.sbib
index 2747e61..1a283e9 100644
--- a/doc/programming-2022/security.sbib
+++ b/doc/programming-2022/security.sbib
@@ -3,6 +3,8 @@
   (title "Reproducible Builds: Increasing the Integrity of Software Supply 
Chains")
   (publisher "IEEE Computer Society")
   (year "2021")
+  (volume "38")
+  ;; XXX: number?
   (issn "0740-7459")
   (doi "10.1109/MS.2021.3073045")
   (journal "IEEE Software"))
diff --git a/doc/programming-2022/supply-chain.skb 
b/doc/programming-2022/supply-chain.skb
index 4837937..a0ce74f 100644
--- a/doc/programming-2022/supply-chain.skb
+++ b/doc/programming-2022/supply-chain.skb
@@ -450,7 +450,7 @@ attacks in two ways: by reducing and eventually removing 
reliance on
 opaque binaries at the root of its dependency graph, and by affording
 reproducible builds.  Guix users can choose to obtain pre-built binaries
 for software they install, and reproducible builds guarantee that anyone
-can verify that provides of those binaries are not distributing modified
+can verify that providers of those binaries are not distributing modified
 or malicious versions.])
 
       (p [The security issue that the remainder of this paper focuses on
@@ -464,7 +464,8 @@ question has to be approached from a different angle.])
 
       (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
-maintained under version control in a Git repository.  To update Guix
+maintained under version control in a Git repository,(footnote (ref :url 
"https://git-scm.com";)).
+To update Guix
 and its package collection, users run ,(tt [guix pull])—the equivalent
 of ,(tt [apt update]) in Debian.  When users run ,(tt [guix pull]), what
 happens behind the scene is equivalent to ,(tt [git clone]) or ,(tt [git
@@ -484,10 +485,19 @@ repository can push code, which every user would then 
pull.  The
 change might even go unnoticed and remain in the repository forever.
 They may also reset the main branch to an earlier revision, leading
 users to install outdated software with known vulnerabilities—a ,(emph
-[downgrade attack]).  Likewise, the attacker may change the main branch
+[downgrade attack]) ,(ref :bib '(cappos2008:attacks kuppusamy2017:mercury
+torresarias2016:omitting)).
+Likewise, the attacker may change the main branch
 reference so it points to a different branch, containing new malicious
-code—a ,(emph [teleport attack]) ,(ref :bib 'torresarias2016:omitting).
-These are the kind of attacks we want to protect against.]))
+code—a ,(emph [teleport attack]) ,(ref :bib 'torresarias2016:omitting).])
+
+      (p [To summarize, we want to protect against attacks that could be
+made by gaining access to the Git repository of Guix: introduction of
+malicious changes by the attacker, downgrade attacks, and teleport
+attacks.  We do ,(emph [not]) aim to protect against cases where an
+attacker is able to impersonate an authorized developer or otherwise
+force them into pushing malicious changes; in our model, authorized
+developers are ultimately trusted.]))
    
    (chapter :title [Authenticating Git Checkouts]
       :ident "authenticating"
@@ -499,7 +509,7 @@ obtains code from Git, it should be able to tell that all 
the commits it
 fetched were pushed by authorized developers of the project.  We are
 really looking at individual commits, not tags, because users can choose
 to pull at arbitrary points in the commit history of Guix and of third-party
-channels.  Quite surprisingly, we found that similar Git-backed source-based
+channels.  Surprisingly, we found that similar Git-backed source-based
 deployment tools such as Nix do not address this problem, and there were no
 existing tools or protocols supporting off-line checkout authentication to
 our knowledge—we get back to that in ,(numref :text [Section] :ident
@@ -530,7 +540,10 @@ somebody else’s changes after review.  Checkout 
authentication requires
 cryptographically signed commits.  It also requires a notion of
 authorization: we do not simply want commits to have a valid signature,
 we want them to be signed by an authorized key.  The set of authorized
-keys changes over time as people join and leave the project.])
+keys changes over time as people join and leave the project.  The
+authentication mechanism must be able to deal with those changes; a
+developer’s signature may only be considered valid for the period during
+which the developer was officially an authorized committer.])
 
       (p [To implement that, we came up with the following mechanism and rule:
 
@@ -542,8 +555,8 @@ keys changes over time as people join and leave the 
project.])
      of the keys listed in the ,(tt [.guix-authorizations]) file of each of
      its parents.  We call this the ,(emph [authorization invariant]).]))
      
-The ,(tt [.guix-authorizations]) format is a Lisp-style s-expression (or
-“sexp”), as shown in ,(numref :text [Figure] :ident
+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
 structured format leaves room for extensions, such as per-file
@@ -579,7 +592,7 @@ development branch, while the purple line may correspond to 
a feature
 branch that was eventually merged in commit ,(it [F]).  ,(it [F]) is a
 merge commit, so it has two parents: ,(it [D]) and ,(it [E]).])
 
-      (p [Labels next to boxes show who’s in ,(tt [.guix-authorizations]): for 
commit A,
+      (p [Labels next to boxes show who is in ,(tt [.guix-authorizations]): 
for commit A,
 only Alice is an authorized committer, and for all the other commits,
 both Bob and Alice are authorized committers.  For each commit, the
 authorization invariant holds; for example:
@@ -721,16 +734,18 @@ authorization invariant.]))
    (chapter :title [Downgrade Attacks] :ident "downgrade"
       
       (p [An important threat for software deployment tools is
-,(emph [downgrade]) or ,(emph [roll-back]) attacks.  The attack consists in 
tricking
+,(emph [downgrade attacks]), also called ,(emph [roll-back])
+or ,(emph [replay]) attacks ,(ref :bib '(cappos2008:attacks 
kuppusamy2017:mercury)).
+The attack consists in tricking
 users into installing older, known-vulnerable software packages, which
 in turn may offer new ways to break into their system.  This is not
 strictly related to the authentication issue discussed above, but it is
 an important issue that is more easily addressed with this model in
 place.])
 
-      (p [Guix saves provenance info for itself: the ,(tt [guix
-describe]) command prints that information, essentially the Git commits
-of the channels used during ,(tt [git pull]):]
+      (p [Guix saves information about its own provenance—the Git
+commits of the channels used by ,(tt [guix pull]).  The ,(tt [guix
+describe]) command prints that information:]
 
      (prog :class "small" :line #f [
 $ guix describe
@@ -791,8 +806,10 @@ downgrade prevention is implemented at this level.]))
    (chapter :title [Mirrors and the Risk of Staleness]
       :ident "mirrors"
 
-      (p [Authentication and roll-back prevention allow users to safely
-refer to mirrors of the Git repository.  If the official repository at
+      (p [For package managers, mirrors of the official repositories
+are a known security risk ,(ref :bib 'cappos2008:attacks).
+Authentication and roll-back prevention as described above allow users to 
safely
+refer to mirrors of the official Git repository of Guix.  If the official 
repository at
 ,(tt [git.savannah.gnu.org]) is down, one can still update by fetching
 from a mirror, for instance with:]
 
@@ -943,7 +960,19 @@ 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.]))
+experience.])
+
+        (p [Another performance aspect has to do with Git repository
+handling.  The mechanisms we devised for commit authentication and
+downgrade prevention assume the availability of a local copy of the Git
+repository, including its history.  The first time a user invokes ,(tt
+[guix pull]), the command clones the repository, downloading more than
+300 MiB—this can take minutes, much longer than the commit
+authentication phase.  Currently that operation performs a full clone,
+including the whole repository history, but it may be possible to
+optimize it by performing a ,(emph [shallow clone]), where only recent
+history is retrieved.  Subsequent runs are much faster and lightweight,
+as Git is able to download just what is missing from the local copy.]))
       
       (section :title [Generalization]
         
@@ -986,7 +1015,7 @@ represented as a single 56-character base64 string, or as 
a QR code.
 For broad acceptance, the best option would be to integrate the
 functionality in Git proper.]))
 
-      (section :title [Experience]
+      (section :title [Evaluation]
         
         (p [Channel authentication as described above has been deployed
 and used in production in Guix for more than a year, since June 2020.
@@ -994,10 +1023,10 @@ This has given us an informal but large-scale, 
“real-world” evaluation
 of this work.  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 one year, there was one
+authentication and downgrade prevention.  In almost two years, there was one
 incident where a committer mistakenly pushed a commit signed with an
 unauthorized key, which was immediately detected by anyone who attempted
-to run ,(tt [guix pull]), and the offending commit was removed in
+to run ,(tt [guix pull]); the offending commit was removed in
 minutes (with a ,(emph [hard reset]) to its parent commit, in Git
 parlance).  Such mistakes can be avoided by having a server-side hook
 running ,(tt [guix git authenticate]), but we did not have the ability
@@ -1019,11 +1048,11 @@ downgrade prevention mechanism; these users were 
familiar with Git and
 understood that the mechanism rightfully protected them from a
 potential downgrade.])
         
-        (p [System downgrade prevention has already proved helpful.
+        (p [System downgrade prevention has demonstrated its value.
 Since ,(tt [guix system reconfigure]) and ,(tt [guix deploy]) prevent
-downgrades, a sysadmin cannot mistakenly reconfigure the system to and
+downgrades, a system administrator cannot mistakenly reconfigure the system to 
an
 older or unrelated commit; this is particularly useful on systems
-administered by several people, where an administrator cannot mistakenly
+administered by several people, where an administrator cannot
 “undo” the upgrade performed by another administrator.])
         
         (p [More importantly, checkout authentication together with
@@ -1034,9 +1063,9 @@ 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.  Generalized
+been adopting authentication support without hassle.  Outside Guix, generalized
 authentication support offered by ,(tt [guix git authenticate]) has seen
-use in a few repositories beside Guix channels.  We have yet to see
+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.])))