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
|
||||
|
||||
Minimalism and security first repository of reproducible and signed OCI images
|
||||
of common open source software packages built from source.
|
||||
Minimalism and security first repository of reproducible and multi-signed OCI
|
||||
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
|
||||
tools, to bootstrapping a Linux distribution.
|
||||
We built to support very high risk threat models where trusting any single
|
||||
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
|
||||
|
||||
|
@ -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
|
||||
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
|
||||
individual maintainers at best. Modern popular distros often fail to even do
|
||||
this, having a central machine somewhere blindly signing all unsigned
|
||||
|
@ -52,20 +59,42 @@ the future.
|
|||
* Like NixOS
|
||||
* Maintainers sign all package additions/changes
|
||||
* 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.
|
||||
|
||||
### Reproducibility
|
||||
|
||||
* Trust no single external source of binaries
|
||||
* Bootstrap from two different third party signed distros
|
||||
* Never use external binaries
|
||||
* Bootstrap from 0, always, even if it means going back in time
|
||||
* Go, rust require extensive work to bootstrap all the way back to gcc
|
||||
* Guix is the only distro that does this for rust to our knowledge
|
||||
* Full-Source Bootstrap from x86_64 assembly
|
||||
* Take maximum advantage of the hard won wins by the Guix team
|
||||
* Bootstrap from guile driver reproduced on multiple signed distros
|
||||
The only way to produce trustworthy packages is to make sure no single system
|
||||
or human is every trusted in the process of compiling them. Everything we
|
||||
release must be built deterministically. Further to avoid trusting any specific
|
||||
distro or platform, we must be able to reproduce even from wildly different
|
||||
toolchains, architectures, kernels, etc.
|
||||
|
||||
Using OCI container images as our base packaging system helps a lot here by
|
||||
making it easy to throw away non-deterministic build stages and control many
|
||||
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
|
||||
|
||||
|
|
Reference in New Issue