Skip to content

Glossary

Target audience: All users Goal: Definitions of StageX-specific terminology and concepts.

A–B

Attestation A cryptographically signed claim that a specific OCI image digest is the correct output for a given package. StageX attestations are PGP detached signatures over a JSON payload in the Container Signature Format. Each maintainer who independently builds and confirms a digest signs an attestation. Attestations are stored in the signatures repository at stagex/<package>@sha256=<digest>/signature-<N>. See Verify Attestations and Multi-Sig.

Bootstrap chain The complete sequence from hex0-seed through Stage0 → Stage1 → Stage2 → Stage3 → Stage X. Each stage produces the tools needed to build the next. No binary is ever introduced that was not produced by an earlier stage in the same chain. The chain is fully deterministic and independently verifiable. See Bootstrapping Journey and Architecture.

Buildx Docker Buildx plugin (v0.30.1+) — the required OCI build backend for StageX. Provides --output type=oci (OCI layout output), --build-context (composable multi-stage dependencies), rewrite-timestamp=true (deterministic timestamps), and force-compression=true (deterministic compression). The BUILDER Makefile variable controls which backend is used. See Makefile Targets and Dev Environment.

BusyBox A compact implementation of common Unix utilities (sh, ls, cp, sed, awk, etc.) in a single binary. Used in StageX minimal images to provide a functional userland without installing dozens of individual GNU tools. BusyBox is built as a core package and included in pallet images and FROM scratch build stages. See Minimalism and Package Catalog.

C–D

cargo fetch A Cargo subcommand that downloads all crate dependencies for a Rust project and stores them in the vendored vendor/ directory. Used in StageX Containerfiles to pre-populate the crate cache before the hermetic RUN --network=none build step, ensuring all dependencies are available without network access during compilation. See Rust App.

Container Signature Format Standard JSON payload format for OCI image signing. Contains critical.identity.docker-reference, critical.image.docker-manifest-digest, and critical.type ("atomic container signature"). StageX maintainers create PGP signatures over this payload. Podman consumes these signatures via policy.json. See Verify Attestations.

Containerd image store Docker Engine storage backend required by StageX. Enabled via "features": {"containerd-snapshotter": true} in /etc/docker/daemon.json. StageX's build pipeline depends on docker save / docker load interactions that only work with this backend. See Dev Environment, Step 1.

Containerfile The OCI build recipe for each StageX package, located at packages/<stage>/<name>/Containerfile. Uses standard Dockerfile syntax. Key patterns: FROM scratch, COPY --from=stagex/<dep> . / (dependency composition), ADD fetch/<source> (source tarballs), RUN --network=none (hermetic builds), --timestamp 1 (deterministic timestamps). See Containerfile Syntax and Add a Package.

Core Stage X category for low-level infrastructure packages: compilers (LLVM, Go, Rust), libraries (musl, openssl, zlib), and build tools (cmake, make, meson). Core packages may depend only on other core or bootstrap packages. See Package Catalog.

Deterministic build Synonym for "reproducible build" in StageX usage. A build where identical inputs always produce identical outputs, byte-for-byte. Achieved through SOURCE_DATE_EPOCH=1, --network=none, pinned digests, and --frozen lockfiles. See Reproducible Builds.

Digest A SHA-256 hash (64 hex characters) uniquely identifying a specific OCI image manifest. The fundamental unit of identity and verification in StageX. Users pin images by digest (@sha256:...) for immutable, cryptographically verified references. Published in digests/<stage>.txt. See Reproduce Builds.

Diverse double compilation David A. Wheeler's technique for detecting compiler backdoors: the same source code is compiled with two independent compilers and the outputs are compared. Any discrepancy reveals potential subversion. StageX's full-source bootstrap chain provides the practical foundation for this technique across the entire toolchain. See Bootstrapping Journey and Why Bootstrapping.

F–H

FROM scratch The base image directive used by all StageX packages. The final image starts empty and includes only what is explicitly COPY'd in. Produces minimal attack surface and tiny images (e.g., a Rust HTTP server in ~3 MB). See Quick Start and OCI-Native.

Full-source bootstrapping Building every software component from source all the way down to a minimal, auditable trust anchor, with zero pre-compiled binary dependencies. StageX achieves this from a 181-byte hex0-seed through four bootstrap stages. Eliminates the Trusting Trust attack vector. See Bootstrapping Journey and Why Bootstrapping.

Hermetic build A build with no network access during compilation. StageX uses RUN --network=none in Containerfiles to prevent build-time dependency downloads. Critical for reproducibility (eliminates network-dependent behavior) and supply chain security (prevents injection attacks). See Containerfile Syntax and Reproducible Builds.

hex0 A hexadecimal-to-binary converter; the first program built from the 181-byte hex0-seed. Reads ASCII hex bytes separated by whitespace and writes corresponding binary output. The hex0 source is itself written in hex0 format — hand-crafted x86 machine code, no assembler involved. See Bootstrapping Journey, Stage 0.

hex0-seed A 181-byte hand-crafted ELF binary for Intel i386 stored at packages/bootstrap/stage0/hex0-seed. The absolute root of trust — the smallest possible seed from which everything else is built. A 32-bit statically-linked ELF executable that interprets the hex0 format. Its hash has been reproduced identically across multiple Linux distributions. See Bootstrapping Journey.

hex1, hex2 Successively more capable assembler/linker formats in the Stage0 bootstrap chain. hex1 supports x86 instruction mnemonics (not just raw hex). hex2 supports labels, sections, and relocations — capable of producing final linked executables. See Bootstrapping Journey.

L–M

live-bootstrap Fosslinux's project to bootstrap a modern Linux system entirely from source, starting from the stage0 seed and progressing through Mes, tcc, musl, and GCC. StageX uses live-bootstrap as the core of its Stage1 bootstrap phase, providing a complete 32-bit Linux userland. See Bootstrapping Journey, Stage 1.

Lookaside A mechanism where image signatures are stored separately from the image itself. StageX uses a lookaside server at https://sigs.stagex.tools. Podman's registries.d/default.yaml configures the lookaside location. Keeps signatures out of the registry, reducing the registry's blast radius. See Verify Attestations.

Maintainer A trusted individual authorized to sign and publish StageX packages. Listed in MAINTAINERS with PGP key fingerprints and hardware specs. Must follow strict key management (hardware smart cards, PIN protection, touch-required signing). Currently 8 maintainers. See Verify Image, Step 4 and Maintainer's Handbook.

Mes A minimal Scheme-based C compiler that serves as a critical bridge in the bootstrap chain. Mes translates a simple C subset into working machine code, enabling the transition from stage0's limited output to a full C compiler (tcc) without requiring any pre-compiled binary. Part of the live-bootstrap pipeline used in Stage1. See Bootstrapping Journey, Stage 1.

mimalloc Microsoft Research's memory allocator, used as the default allocator in StageX images. Chosen over glibc's allocator for its small code footprint, predictable performance, and strong security properties. Contributes to StageX's minimal attack surface strategy. See Minimalism.

mrustc A minimal Rust compiler implemented in C++. Enables Rust to be full-source bootstrapped from a C compiler without requiring a pre-built Rust binary. Rust is first compiled using mrustc, then the resulting binary is used to compile the full rustc from source. This eliminates the circular dependency that would otherwise require an existing Rust installation. See Bootstrapping Journey.

Multi-party verification The practice of having multiple independent parties each build the same package from source, compare digests, and confirm identical output. StageX requires at least two maintainers to independently verify each package before publication. Catches both malicious tampering and accidental non-determinism. See Multi-Sig and Trust Models.

musl The C standard library used by all StageX images. Chosen over glibc for minimalism (~1/4 the code), better security profile, and superior support for portable static binaries. Default for Rust's x86_64-unknown-linux-musl target. See Quick Start and Minimalism.

O–P

OCI image An Open Container Initiative-compliant container image consisting of a manifest, configuration file, and layer blobs. StageX packages are distributed as OCI images via docker.io/stagex and quay.io/stagex. See OCI Integration and OCI-Native.

OCI layout The on-disk format for OCI images used by StageX's build output (out/<package>/index.json + blobs/sha256/<digest>). The intermediate format between building and publishing. See Reproduce Builds and Makefile Targets.

OCI-native StageX's architectural philosophy of using OCI layers as the native package format instead of traditional package managers (APT, DNF, Pacman). Packages are OCI images built FROM scratch; COPY --from=stagex/<dep> . / replaces apt install <dep>; image digests replace version numbers; multi-sig on container images replaces GPG-signed repositories. See OCI-Native and Containerfile Syntax.

Package.toml The TOML metadata file defining a StageX package (packages/<stage>/<name>/package.toml). Contains [package] fields (name, version, description, license, website) and [sources.*] sections (hash, format, file, git_sha, mirrors). Supports template placeholders {version}, {version_major}, {format}, {file} etc. See Package.toml Format and Add a Package.

Pallet A language runtime image — a FROM scratch OCI image containing all tools needed to build programs in a given language. Pallets are the primary developer entry point. Examples: pallet-rust (rustc, cargo, clang/lld, openssl, curl, git, binutils), pallet-python, pallet-go, pallet-nodejs, pallet-cgo. See Quick Start and Package Catalog.

Preseed The process of seeding the build cache by pulling previously published OCI images rather than rebuilding from source. Running make preseed downloads the last published release's images into out/. A convenience for developers building a single new package without rebuilding the entire bootstrap chain. See Reproduce Builds and Makefile Targets.

Q–R

Quorum signing The requirement that every published StageX artifact must be signed by at least two independent maintainers before release. Enforced by publish-* Makefile targets. A compromise would require simultaneously subverting two maintainers' independent build environments. See Multi-Sig and Trust Models.

Release branch Git branches following release/YYYY.MM.<revision> (e.g., release/2026.05.0). Created via make prep-release-branch. All packages on a release branch must be reproduced on at least 2 different CPU vendors and have 2+ signatures. See Release Process and Maintainer's Handbook.

Reproducible build (bit-for-bit) A build producing identical binary output every time, regardless of when, where, or by whom it is built. StageX achieves this through pinned toolchain digests, SOURCE_DATE_EPOCH=1, hermetic builds (--network=none), and locked dependencies. Two maintainers on different machines can compare digests and confirm identical output. See Quick Start, Step 5 and Reproducible Builds.

S

SLSA Supply-chain Levels for Software Artifacts — a security framework for incrementally improving software supply chain integrity. SLSA defines ascending levels (SLSA 1–4) based on build requirements such as provenance, hermeticity, and reproducibility. StageX's combination of full-source bootstrapping, multi-sig quorum signing, and deterministic builds aligns with SLSA 4 requirements for build integrity and provenance. See Reproducible Builds and Multi-Sig.

SOURCE_DATE_EPOCH Environment variable set to 1 (Unix epoch + 1 second) for all StageX builds. Forces all build tools to use a fixed timestamp instead of the current time, eliminating a common source of non-determinism. See Makefile Targets and Reproducible Builds.

Stage0, Stage1, Stage2, Stage3, Stage X The five stages of the bootstrap chain: - Stage0 — 181-byte hex0-seed → hex0/1/2, M2-Planet, kaem, utilities (~2 MB, 32-bit) - Stage1 — Complete 32-bit Linux userland via live-bootstrap: mes, tcc, musl, GCC 4.0.4→13.1.0 (~300 MB) - Stage2 — Cross-compiler bridge from 32-bit to x86_64 and aarch64 (~700 MB) - Stage3 — Native 64-bit toolchain: GCC 13.1.0, binutils, cmake, make, python, busybox (~1 GB) - Stage X — Everything else: pallets, core, and 300+ user packages

See Bootstrapping Journey and Architecture.

Staging branch The integration branch in StageX's Git workflow. All pull requests flow through staging before reaching main: PR branch → staging → release/YYYY.MM.N → staging → main. Ensures every change is reviewed and tested before release. See Maintainer's Handbook.

Static binary A compiled program with no external library dependencies at runtime — all required libraries linked directly into the executable. StageX encourages static linking via Rust's +crt-static or gcc's -static, combined with musl libc. Enables FROM scratch deployment with no shell or libraries. See Rust App and Minimalism.

T–Z

Trusting Trust attack Ken Thompson's 1984 attack demonstrating that a compiler can be modified to insert a backdoor into everything it compiles — and to re-insert that backdoor into its own compiled source, making it invisible even when reading the source. Full-source bootstrapping eliminates this vector entirely. See Bootstrapping Journey, introduction and Why Bootstrapping.

User Stage X category for application packages built using pallets. Includes databases (postgresql, redis), CLI tools (jq, kubectl, helm), editors (vim), system utilities (strace, gdb), and language-specific libraries (290+ packages). Used by downstream projects like AirgapOS and ReprOS. See Package Catalog.

Version_from A package.toml field used by pallets to inherit version from their corresponding core package (e.g., pallet-rust has version_from = "core-rust"). Avoids duplicating version information. See Package.toml Format and Add a Package.

See Also