update intro and background
This commit is contained in:
parent
5cc99f5692
commit
8516e6f9ee
57
README.md
57
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
|
||||
|
|
Reference in New Issue