31/66: programming-2022: Expand "Related Work".

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit d882628c1e318802802b4fc964cc9f18bbc64d11
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Mon Jan 17 21:37:47 2022 +0100

    programming-2022: Expand "Related Work".
    
    * doc/programming-2022/supply-chain.skb (Introduction): Cite
    "samuel2010:survivable" and "cappos2008:attacks".  Clarify what Guix is.
    (Authenticating Git Checkouts): Add forward-reference to "Related Work".
    (Related Work): Mention Mercury, Nix, Brew, Gentoo, etc.
    * doc/programming-2022/security.sbib: Add references.
---
 doc/programming-2022/security.sbib    | 77 +++++++++++++++++++++++++++++++
 doc/programming-2022/supply-chain.skb | 85 +++++++++++++++++++++++++++++------
 2 files changed, 148 insertions(+), 14 deletions(-)

diff --git a/doc/programming-2022/security.sbib 
b/doc/programming-2022/security.sbib
index 1425fd4..2747e61 100644
--- a/doc/programming-2022/security.sbib
+++ b/doc/programming-2022/security.sbib
@@ -39,6 +39,55 @@
   (month "September")
   (url "https://github.com/hannesm/conex-paper/raw/master/paper.pdf";))
 
+(misc nixos2021:signed-commits
+  (author "Nix contributors")
+  (url "https://github.com/NixOS/rfcs/pull/100";)
+  (title "[RFC 0100] Sign commits")
+  (year "2021")
+  (month "August"))
+  
+(misc dolstra2019:flake-auth
+  (author "Eelco Dolstra")
+  (url "https://github.com/NixOS/nix/issues/2849";)
+  (title "Flake authentication")
+  (year "2019")
+  (month "March"))
+  
+(misc brew2022:github
+  (url "https://github.com/Homebrew/brew";)
+  (title "Brew source code")
+  (year "2022")
+  (month "January")
+  (author "Brew contributors"))
+
+(misc condaforge2022:web
+  (url "https://conda-forge.org/";)
+  (title "CONDA-Forge Web site")
+  (year "2022")
+  (month "January")
+  (author "CONDA-Forge contributors"))
+  
+(misc freebsd2022:handbook
+  (url "https://docs.freebsd.org/en/books/handbook/";)
+  (title "FreeBSD Handbook")
+  (year "2022")
+  (month "January")
+  (author "The FreeBSD Documentation Project"))
+
+(misc pkgsrc2022:guide
+  (url "https://www.netbsd.org/docs/pkgsrc/";)
+  (title "The pkgsrc Guide")
+  (year "2022")
+  (month "January")
+  (author "The pkgsrc Developers"))
+  
+(misc gentoo2022:portage-security
+  (url "https://wiki.gentoo.org/wiki/Portage_Security";)
+  (title "Portage Security")
+  (year "2022")
+  (month "January")
+  (author "Gentoo developers"))
+
 (inproceedings torresarias2016:omitting
 (author "Santiago Torres-Arias and Anil Kumar Ammula and Reza Curtmola and 
Justin Cappos")
 (title "On Omitting Commits and Committing Omissions: Preventing Git Metadata 
Tampering That (Re)introduces Software Vulnerabilities")
@@ -51,6 +100,18 @@
 (publisher "USENIX Association")
 (month "August"))
 
+(inproceedings kuppusamy2017:mercury
+  (author "Trishank Karthik Kuppusamy and Vladimir Diaz and Justin Cappos")
+  (title "Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against 
Community Repositories")
+  (booktitle "2017 USENIX Annual Technical Conference (USENIX ATC 17)")
+  (year "2017")
+  (isbn "978-1-931971-38-6")
+  (address "Santa Clara, CA")
+  (pages "673--688")
+  (url 
"https://www.usenix.org/conference/atc17/technical-sessions/presentation/kuppusamy";)
+  (publisher "USENIX Association")
+  (month "July"))
+
 (inproceedings torresarias2019:intoto
 (author "Santiago Torres-Arias and Hammad Afzali and Trishank Karthik 
Kuppusamy and Reza Curtmola and Justin Cappos")
 (title "in-toto: Providing farm-to-table guarantees for bits and bytes")
@@ -63,6 +124,22 @@
 (publisher "USENIX Association")
 (month "Aug"))
 
+(inproceedings cappos2008:attacks
+(author "Justin Cappos and Justin Samuel and Scott Baker and John H. Hartman")
+(title "A Look in the Mirror: Attacks on Package Managers")
+(year "2008")
+(isbn "9781595938107")
+(publisher "Association for Computing Machinery")
+(address "New York, NY, USA")
+(url "https://doi.org/10.1145/1455770.1455841";)
+(doi "10.1145/1455770.1455841")
+(booktitle "Proceedings of the 15th ACM Conference on Computer and 
Communications Security")
+(pages "565–574")
+(numpages "10")
+(keywords "package management, replay attack, mirrors")
+(location "Alexandria, Virginia, USA")
+(series "CCS '08"))
+
 (article hinsen2020:staged-computation
   (author "Konrad Hinsen")
   (journal "Computing in Science Engineering")
diff --git a/doc/programming-2022/supply-chain.skb 
b/doc/programming-2022/supply-chain.skb
index 69e3a4a..b992ab1 100644
--- a/doc/programming-2022/supply-chain.skb
+++ b/doc/programming-2022/supply-chain.skb
@@ -185,11 +185,16 @@ a key position when it comes to securing the “software 
supply
 chain”—they take source code fresh from repositories and providing users
 with ready-to-use binaries.  Between source code repositories and
 binaries users run, many things can go wrong: binaries can be
-compromised on their way to the user's machine, on the provider's
-servers, or possibly indirectly ,(it [via]) toolchain compromission
-,(ref :bib "thompson1984:trusting-trust").  Every software installation
-and every upgrade can put users at risk.  Recent high-profile cases have
-reminded us that software supply chain attacks are a very real threat
+compromised on their way to the user's machine ,(ref :bib
+'cappos2008:attacks), on the provider's servers, or possibly indirectly
+,(it [via]) toolchain compromission ,(ref :bib
+"thompson1984:trusting-trust").  Every software installation and every
+upgrade can put users at risk.  As the “last kilometer” of this supply
+chain, the way package managers distribute binaries and associated
+metadata led to security vulnerabilities that are now better understood
+and addressed ,(ref :bib 'samuel2010:survivable).  But recent
+high-profile cases have reminded us that software supply chain attacks
+occurring ,(emph [before]) the distribution step are a very real threat
 ,(ref :bib '(lamb2021:reproducible peisert2021:solarwinds)).  This led,
 for example, the US Government to call for work in this area in its
 Executive Order on cybersecurity, explicitly mentioning actions such as
@@ -199,10 +204,12 @@ 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 similar
-in spirit to Debian’s apt or Fedora’s yum.  Unlike those, Guix builds
-upon the ,(emph [functional deployment model]) pioneered by Nix ,(ref
-:bib "dolstra2004:nix"), a foundation for reproducible deployment,
+standalone GNU/Linux distribution.  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
+builds upon the ,(emph [functional deployment model]) pioneered by Nix
+,(ref :bib "dolstra2004:nix"), a foundation for reproducible deployment,
 reproducible builds, and provenance tracking.  Guix is essentially a
 “source-based” deployment tool: the ,(emph [model]) is that of a system
 where every piece of software is built from source, and pre-built
@@ -415,9 +422,9 @@ is that of ,(emph [distributing updates securely]): how can 
users know
 that updates to Guix and its package collection that they fetch are
 genuine?  The problem of securing software updates is often viewed
 through the lens of binary distributions such as Debian, where the main
-asset to be protected are binaries themselves.  Guix being a
-source-based distribution, the question has to be approached from a
-different angle.])
+asset to be protected are binaries themselves ,(ref :bib
+'cappos2008:attacks).  Guix being a source-based distribution, the
+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
@@ -456,8 +463,11 @@ 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, there were no existing tools or protocols
-supporting off-line checkout authentication to our knowledge.])
+channels.  Quite 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
+"related").])
       
       (p [Git is an append-only, content-addressed version control
 system.  Revision history in Git is represented by a graph of commit
@@ -1011,6 +1021,18 @@ attacks TUF aims to protect against (Section 1.5.2 of 
the spec), the
 downgrade-prevention mechanism described in ,(numref :text [Section]
 :ident "downgrade") does not, ,(it [per se]), address ,(it [indefinite
 freeze attacks]) (more on that below).])
+      
+      (p [Mercury is a variant of TUF that intends to protect against
+downgrade attacks even in the face of compromised repositories ,(ref
+:bib 'kuppusamy2017:mercury).  Mercury focuses on package version
+strings to determine what constitutes a downgrade.  This is a
+restrictive definition of downgrade that relies on presumed conventions
+used by repository maintainers.  In contrast, looking at the package
+commit graph as described in ,(numref :text [Section] :ident
+"downgrade") allows us to capture the evolution of packages and of the
+distribution ,(emph [as a whole]).  However, while our approach requires
+users to download a complete copy of the Git repository, Mercury has
+much lower bandwidth requirements.])
 
       (p [However, both in its goals and system descriptions, TUF is
 biased towards systems that distribute binaries as plain files with
@@ -1027,6 +1049,41 @@ 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
+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
+two reasons: (1) it would make it impossible to perform Git merges
+(accepting “pull requests”) from the GitHub web interface, and (2)
+GitHub is effectively considered a trusted third party ,(ref :bib
+'nixos2021:signed-commits).  Nix also features a newer and more
+decentralized mechanism to distribute packages called ,(emph [flakes]);
+flake authentication has been discussed but those discussions have not
+come to fruition yet ,(ref :bib 'dolstra2019:flake-auth).])
+      
+      (p [Other package managers have a similar setup: Brew updates its
+package repositories from GitHub, using Git, but without any particular
+mechanism to ensure checkout authenticity ,(ref :bib 'brew2022:github);
+likewise, CONDA-Forge, a set of Git repositories hosting package recipes
+for the CONDA package manager, does not offer any authentication
+mechanism ,(ref :bib 'condaforge2022:web), and FreeBSD Ports are in a
+similar situation ,(ref :bib 'freebsd2022:handbook).  The source-based
+pkgsrc tool, used on NetBSD, updates its set of package recipes using
+the CVS version control system, which allows neither for authentication
+nor for integrity checks ,(ref :bib 'pkgsrc2022:guide).])
+      
+      (p [Gentoo, a source-based GNU/Linux distribution, stores package
+definitions in a Git repository where commits are required to be signed
+by developers; the project maintains a separate list of currently
+authorized developer keys ,(ref :bib 'gentoo2022:portage-security).
+Because the list of authorized keys is separate, it is not clear how to
+verify whether a given commit is signed by a key that was authorized at
+the time of signature.  Another shortcoming is that the recommended
+method to update one’s local copy of the package repository is ,(emph
+[not]) Git but instead the rsync file synchronization protocol together
+with OpenPGP signatures of the files made with special-purpose a release
+key.])
+
       (p [Developers of OPAM, the package manager for the OCaml
 language, adapted TUF for use with their Git-based package repository,
 later updated to write Conex ,(ref :bib 'mehnert2016:conex), a separate