More detail on goals and bootstrapping
This commit is contained in:
parent
b1bee039f0
commit
abc7389e4e
59
README.md
59
README.md
|
@ -1,10 +1,17 @@
|
||||||
# Packages
|
# Packages
|
||||||
|
|
||||||
Minimalism and security first repository of reproducible and signed OCI images
|
Minimalism and security first repository of reproducible and multi-signed OCI
|
||||||
of common open source software packages built from source.
|
images of common open source software packages full-source bootsrapped from
|
||||||
|
Stage 0 all the way up.
|
||||||
|
|
||||||
These can be used as a secure supply chain for anything from obtaining local
|
We built to support very high risk threat models where trusting any single
|
||||||
tools, to bootstrapping a Linux distribution.
|
system or maintainer in our software supply chain cannot be tolerated. That
|
||||||
|
said, we should also function as a drop-in replacement for musl-based linux
|
||||||
|
distributions for virtually any threat model.
|
||||||
|
|
||||||
|
Our aim is to provide a reasonably secure set of toolchains for every major
|
||||||
|
programming language to be the basis of your containers, build systems,
|
||||||
|
firmware, secure enclaves, or hosting infrastructure.
|
||||||
|
|
||||||
## Background
|
## Background
|
||||||
|
|
||||||
|
@ -13,7 +20,7 @@ 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
|
assigns trust of significant components to single human points of failure, is
|
||||||
doomed to have failure.
|
doomed to have failure.
|
||||||
|
|
||||||
Most linux distributions rely on complex package management systems for which
|
Most Linux distributions rely on complex package management systems for which
|
||||||
only a single implementation exists. They assign package signing privileges to
|
only a single implementation exists. They assign package signing privileges to
|
||||||
individual maintainers at best. Modern popular distros often fail to even do
|
individual maintainers at best. Modern popular distros often fail to even do
|
||||||
this, having a central machine somewhere blindly signing all unsigned
|
this, having a central machine somewhere blindly signing all unsigned
|
||||||
|
@ -52,20 +59,42 @@ the future.
|
||||||
* Like NixOS
|
* Like NixOS
|
||||||
* Maintainers sign all package additions/changes
|
* Maintainers sign all package additions/changes
|
||||||
* Like Gentoo, Debian, Fedora, Guix
|
* Like Gentoo, Debian, Fedora, Guix
|
||||||
* Reviewers locally build and counter-sign all new binary packages
|
* Reviewers/Reproducers 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
|
### Reproducibility
|
||||||
|
|
||||||
* Trust no single external source of binaries
|
The only way to produce trustworthy packages is to make sure no single system
|
||||||
* Bootstrap from two different third party signed distros
|
or human is every trusted in the process of compiling them. Everything we
|
||||||
* Never use external binaries
|
release must be built deterministically. Further to avoid trusting any specific
|
||||||
* Bootstrap from 0, always, even if it means going back in time
|
distro or platform, we must be able to reproduce even from wildly different
|
||||||
* Go, rust require extensive work to bootstrap all the way back to gcc
|
toolchains, architectures, kernels, etc.
|
||||||
* Guix is the only distro that does this for rust to our knowledge
|
|
||||||
* Full-Source Bootstrap from x86_64 assembly
|
Using OCI container images as our base packaging system helps a lot here by
|
||||||
* Take maximum advantage of the hard won wins by the Guix team
|
making it easy to throw away non-deterministic build stages and control many
|
||||||
* Bootstrap from guile driver reproduced on multiple signed distros
|
aspects of the build environment. Also, as a well documented spec, it allows
|
||||||
|
our packages to (ideally) be built with totally different OCI toolchains such
|
||||||
|
as Docker, Podman, Kaniko, or Buildah.
|
||||||
|
|
||||||
|
This is only part of the story though, because being able to build
|
||||||
|
deterministically means the compilers that compiler our code themselves must
|
||||||
|
be bootstapped all the way from source code in a deterministic way.
|
||||||
|
|
||||||
|
* Final distributable packages are always OCI container images
|
||||||
|
* OCI allows reproduction by totally different toolchains
|
||||||
|
E.g: Docker, Podman, Kaniko, or Buildah.
|
||||||
|
* OCI allows unlimited signatures on builds as part of the spec
|
||||||
|
* E.g: each party that chooses to reproduce adds their own signature
|
||||||
|
* We always "Full Source Bootstrap" everything from 0
|
||||||
|
* [Stage0](src/bootstrap/stage0/Dockerfile): 387 bytes of x86 assembly built by 3 distros with the same hash
|
||||||
|
* Also the same hash many others get from wildly different toolchains
|
||||||
|
* Relevant: [Guix: Building From Source All The Way Down](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)
|
||||||
|
* [Stage1](src/bootstrap/stage1/Dockerfile): A full x86 toolchain built from stage0 via [live-bootstrap](https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst)
|
||||||
|
* [Stage2](src/bootstrap/stage2/Dockerfile): Cross toolchain bridging us to modern 64 bit architectures
|
||||||
|
* [Stage3](src/bootstrap/stage3/Dockerfile): Native toolchain in native 64 bit architecture
|
||||||
|
* [Stage(x)](.): Later stages build the distributed packages in this repo
|
||||||
|
|
||||||
|
For further reading see the [Bootstrappable Builds](https://bootstrappable.org/) Project.
|
||||||
|
|
||||||
### Minimalism
|
### Minimalism
|
||||||
|
|
||||||
|
|
Reference in New Issue