README.md

@@ -1,43 +1,32 @@
 # Packages
 
-Minimalism and security first repository of reproducible and signed OCI images
-of common open source software packages built from source.
+`packages` is a security first repository of [reproducible](https://en.wikipedia.org/wiki/Reproducible_builds) and [cryptographically signed](https://en.wikipedia.org/wiki/Digital_signature) OCI images (used by Docker, Podman, Buildah etc.) of common open source software packages built from source.
 
-These can be used as a secure supply chain for anything from obtaining local
-tools, to bootstrapping a Linux distribution.
+These images can be used as part of a secure supply chain strategy for a wide variety of use-cases. Some examples include local environment setup, hardening CI/CD pipelines or bootstrapping Linux distributions used in production.
 
 ## Background
 
-We have learned a lot of lessons about supply chain integrity over the years,
-and the greatest of them may be that any system that is complex to review and
-assigns trust of significant components to single human points of failure, is
-doomed to have failure.
+We have learned a lot of lessons about supply chain integrity over the years
+and the greatest of them may be that any system that is complex to review, and
+assigns trust of significant components to individuals, creates enormous single 
+points of failure which will lead to eventual compromise.
 
-Most linux distributions rely on complex package management systems for which
-only a single implementation exists. They assign package signing privileges to
-individual maintainers at best. Modern popular distros often fail to even do
-this, having a central machine somewhere blindly signing all unsigned
-contributions from the public.
+Distros (Linux distributions) rely on complex package management systems for which
+only a single implementation exists. They typically generate a lot of custom tooling, 
+which in turn rapidly grows in complexity to meet demands ranging from hobby desktops to 
+production servers. This complexity demands a lot of effort to maintain, and in practice
+results in a tendency to reduce security overhead in order to lower the barrier to 
+entry to attract more maintainers. As a result, projects rarely mandate cryptographic 
+signing or reproducible builds, let alone multiple signed reproduction proofs. In fact, 
+some popular distros use a server to blindly sign all contributions from the public, which 
+can give a false sense of security to the unassuming user.
 
 We will cover an exhaustive comparison of the supply chain strategies of other
-package management solutions elsewhere, but suffice to say while many are
-pursuing reproducible builds, minimalism, or signing... any one solution
-delivering on all of these does not seem in the cards any time soon.
-
-This is generally a human problem. Most solutions end up generating a lot of
-custom tooling for package management, which in turn rapidly grows in
-complexity to meet demands ranging from hobby desktop systems production
-servers.
-
-This complexity demands a lot of cycles to maintain, and this means in practice
-lowering the barrier to entry to allow any hobbyist to contribute and maintain
-packages with minimal friction and rarely a requirement of signing keys or
-mandatory reproducible builds, let alone multiple signed reproduction proofs.
-
-Suffice to say, we feel every current Linux package management solution and
-container supply chain has single points of human failure, or review
-complexity, that makes it undesirable for threat models that assume any single
-human can be hacked or coerced.
+package management solutions elsewhere, but while many are pursuing reproducible builds, 
+minimalism, or signing, there isn't a solution which delivers on all of these basic 
+tenets of supply chain security. `packages` is an attempt to fix this, in order to satisfy
+the criteria of reasonably secure supply chain strategy which requires more
+than one individual to deterministically build and sign software. 
 
 ## Goals
 
@@ -53,7 +42,7 @@ the future.
 * Maintainers sign all package additions/changes
     * Like Gentoo, Debian, Fedora, Guix
 * Reviewers locally build and counter-sign all new binary packages
-    * No one does this, as far as we can tell.
+    * **No one does this, as far as we can tell.**
 
 ### Reproducibility
 
@@ -86,7 +75,7 @@ the future.
 ### Requirements
 
 * An OCI building runtime
-    * Currently Docker supported, but will support buildah and podman
+    * Currently Docker supported, but will support Buildah and Podman
 * Gnu Make
 
 ### Examples
@@ -126,7 +115,7 @@ make sign
 Every package should have a minimum of 5 stages as follows
 
 * base
-    * based on busybox or bootstrap
+    * Based on busybox or bootstrap
     * Runs as unprivileged user 1000 (user)
     * Sets environment to be shared with fetch, build, and install stages
     * Imports dependencies for fetch, build, and install stages