update intro and background #1

Closed
anton wants to merge 1 commits from feat/update-readme into main
1 changed files with 23 additions and 34 deletions
Showing only changes of commit 8516e6f9ee - Show all commits

View File

@ -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