23/66: icse-2022: Address CCS reviewer comments.

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit 5cb0c78127c4511bba2bf4fda073a83a5671b9ed
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Tue Aug 31 11:51:55 2021 +0200

    icse-2022: Address CCS reviewer comments.
---
 doc/icse-2022/supply-chain.skb | 39 +++++++++++++++++++++++++--------------
 1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/doc/icse-2022/supply-chain.skb b/doc/icse-2022/supply-chain.skb
index af6888a..c10660d 100644
--- a/doc/icse-2022/supply-chain.skb
+++ b/doc/icse-2022/supply-chain.skb
@@ -407,8 +407,9 @@ not specific to Guix and to software deployment tools: it’s 
about
 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 third-party
-channels.])
+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.])
       
       (p [Git is an append-only, content-addressed version control
 system.  Revision history in Git is represented by a graph of commit
@@ -433,7 +434,7 @@ commit, a Guix developer asserts that they are the one who 
made the
 commit; they may be its author, or they may be the person who applied
 somebody else’s changes after review.  Checkout authentication requires
 cryptographically signed commits.  It also requires a notion of
-authorization: we don’t simply want commits to have a valid signature,
+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.])
 
@@ -842,10 +843,13 @@ our context is the causality of commits: that a signature 
on a commit is
 valid and authorized.  Likewise, revocation makes little sense in this
 context; what matters is whether the authorization invariant holds.])
 
-        (p [As an indication, 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, which is fast
-enough to not be detrimental to the user experience.]))
+        (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.]))
       
       (section :title [Generalization]
         
@@ -891,8 +895,10 @@ functionality in Git proper.]))
       (section :title [Experience]
         
         (p [Channel authentication as described above has been deployed
-and used in production in Guix for a year, since June 2020.  At that
-time, users who ran ,(tt [guix pull]) transparently obtained the new
+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,
+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
 incident where a committer mistakenly pushed a commit signed with an
@@ -912,14 +918,17 @@ to pull back to the main branch, ,(tt [guix pull]) would 
report an
 error saying that the target commit is “unrelated” to the source
 commit.  Indeed, because the development branch has not been merged into
 the main branch, the latest commit on the main branch is not a
-descendant of the latest commit on the development branch.  Some users
-were initially surprised but quickly understood the value of this
-protection.])
+descendant of the latest commit on the development branch.  Since this
+mechanism is in production, we had only two reports from advanced users
+“surprised” that switching branches in such a way would trigger the
+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.
 Since ,(tt [guix system reconfigure]) and ,(tt [guix deploy]) prevent
 downgrades, a sysadmin cannot mistakenly reconfigure the system to and
-older or unrelated commit; this is particularly useful on system
+older or unrelated commit; this is particularly useful on systems
 administered by several people, where an administrator cannot mistakenly
 “undo” the upgrade performed by another administrator.])
         
@@ -1038,7 +1047,9 @@ verifiability (the functional model and reproducible 
builds make it easy
 to (re)build binaries and check whether they match the source), and
 secure updates (users updating Guix can only get genuine code vetted by
 the project).  We think this is a solid foundation that addresses common
-software supply chain issues at their core.])
+software supply chain issues at their core.  This is a radical, novel
+approach in a time where most related work focuses on certifying each
+link of the supply chain as opposed to ensuring verifiability.])
 
       (p [The security of free operating systems of course also depends
 on the security of the upstream software packages being distributed.  We