Trusted Build Inputs

This inventory covers the build inputs currently trusted by the capOS boot image, generated bindings, host tooling, and verification paths. It started as the S.10.0 inventory and now records the S.10.2 generated-code drift check. It now also records the S.10.3 dependency policy.

Summary

S.10.3 Dependency Policy

Dependency changes are accepted only if they satisfy this policy and are recorded in the owning task checklist.

Dependency classes

Use these classes when reviewing a dependency change:

• Kernel-critical no_std: crates used directly by kernel, capos-lib, and capos-config.
• Userspace-runtime no_std: crates used by init, demos, and capos-rt.
• Host/build: crates used by tools/*, build.rs helpers, and generated output pipelines.
• Test/fuzz/dev: crates gated by dev-dependencies or target-specific for fuzz/proptests/smoke support.

Required pre-merge criteria

For any added dependency (or bump in any class):

1. Manifest and features are explicit. Dependency entries must include explicit feature choices; avoid default-features = true unless justified.
2. No_std compatibility is proven for no_std classes. Kernel-critical and userspace-runtime dependencies must compile in a #![no_std] mode with alloc where expected. cargo build -p <crate> --target x86_64-unknown-none must succeed for every kernel/no_std crate affected.
3. Security policy checks run and pass. CI-equivalent checks for the touched workspace are required through make dependency-policy-check, which runs cargo deny check on every Cargo manifest and cargo audit on every lockfile.
4. Dependency class change is justified in review. PR text must include target class, ownership rationale, transitive graph impact, and why the crate is not a transitive replacement for an already-allowed dependency.
5. Lockfile behavior is explicit. Update only intended lockfiles and record intentional cross-workspace drift in this document if workspace purpose differs.

No_std add/edit checklist

• Reject crates that require std, OS I/O, or unsupported platform APIs in the dependency path intended for kernel classes.
• Reject dependencies that re-export broad platform facades or large unsafe surface unless there is a replacement with smaller scope and better audit visibility.
• Record a license and supply-chain review result (via policy checks) before merge.
• Confirm no unsafe contract escapes are added without a review surface note in the relevant module.

Standing requirements

• Add S.10.3 checks to the target branch plan item for any kernel/no_std crate dependency change and document the exact pass command set.
• Keep lockfile deltas review-visible in normal PR flow; lockfile pinning is the minimum bar, not the gate.
• Keep transitive drift in sync with the trust class: class-wide divergence across lockfiles requires explicit justification.

Remaining gaps after S.10.3 policy

• Continue Rust toolchain pinning work (date/hash pin, reproducible host compiler inputs) as a separate build-reproducibility task.
• Decide whether final ISO/payload hashes become policy-grade inputs in production-hardening stages.

Bootloader and ISO Inputs

The Makefile now pins Limine at commit aad3edd370955449717a334f0289dee10e2c5f01 and verifies these copied artifacts:

make limine-ensure clones https://github.com/limine-bootloader/limine.git only when limine/.git is absent, fetches the pinned commit if needed, checks it out detached, and runs make inside the Limine tree (Makefile:34-40). make limine-verify then checks the repository HEAD and artifact checksums (Makefile:42-49). The ISO copies the kernel, generated manifest.bin, Limine config, and verified Limine artifacts into iso_root/, runs xorriso, then runs limine bios-install (Makefile:51-65).

Remaining reproducibility gap: Limine source is pinned, but the Limine build host compiler and environment are not pinned or recorded.

Rust Toolchain

rust-toolchain.toml specifies:

• channel = "nightly"
• targets = ["x86_64-unknown-none", "aarch64-unknown-none"]

This is a floating channel pin, not a reproducible toolchain pin. A future rustup resolution can move the compiler even when the repository is unchanged. The current local host resolved to:

• rustc 1.96.0-nightly (2972b5e59 2026-04-03)
• cargo 1.96.0-nightly (888f67534 2026-03-30)
• host target x86_64-unknown-linux-gnu

The Makefile derives HOST_TARGET from rustc -vV (Makefile:12) and uses that for tools/mkmanifest (Makefile:28-29). Cargo aliases in .cargo/config.toml:4-22 hard-code x86_64-unknown-linux-gnu for host tests.

Remaining reproducibility gap: pin the nightly by date or exact toolchain hash, and record required components. Until then, compiler drift can change codegen, linking, lints, and generated bindings without a repository diff.

Cargo Dependencies

The root workspace members are capos-config, capos-lib, and kernel (Cargo.toml:1-4). init/, demos/, tools/mkmanifest/, and fuzz/ are standalone workspaces with their own lockfiles.

Important direct dependencies and current root-lock resolutions:

Standalone lockfile drift observed during this inventory:

Cargo lockfiles pin exact crate versions and crates.io checksums, so ordinary crate upgrades are review-visible through lockfile diffs. They do not, by themselves, define whether a dependency is acceptable for kernel/no_std use, whether multiple lockfiles must converge, or whether advisories/licenses block the build.

S.10.3 policy gate:

• deny.toml defines the shared license, advisory, ban, and source baseline.
• make dependency-policy-check runs cargo deny check on the root workspace, init, demos, tools/mkmanifest, capos-rt, and fuzz.
• The same target runs cargo audit --deny warnings on every checked-in lockfile.
• Local packages are marked publish = false so cargo-deny treats them as private, and local path dependencies include version = "0.1.0" so registry wildcard requirements can remain denied.
• CI installs pinned cargo-deny 0.19.4 and cargo-audit 0.22.1 and runs the target.

Remaining dependency-policy gap: decide whether standalone lockfiles may intentionally drift from the root lockfile, especially for capnp and allocator crates used by userspace.

Cap’n Proto Compiler, Runtime, and Generated Bindings

The trusted Cap’n Proto inputs are:

• schema/capos.capnp, the source schema.
• Repo-local pinned capnp, invoked through the capnpc Rust build dependency via CAPOS_CAPNP.
• capnp runtime crate with default-features = false and alloc.
• capnpc codegen crate.
• Generated capos_capnp.rs written to Cargo OUT_DIR.
• Local no_std patching applied after generation.

kernel/build.rs and capos-config/build.rs both run capnpc::CompilerCommand over ../schema/capos.capnp, then read the generated capos_capnp.rs, assert that the expected #![allow(unused_variables)] anchor is present, and inject:

#![allow(unused)]
#![allow(unused_imports)]
fn main() {
use ::alloc::boxed::Box;
use ::alloc::string::ToString;
}

The generated code used by builds is included from OUT_DIR in capos-config/src/lib.rs:10-12 and kernel/src/main.rs:15-18. The expected patched output is checked in as tools/generated/capos_capnp.rs, so schema, compiler, capnpc crate, and patch-output changes must update that baseline and become review-visible as a source diff.

S.10.2 generated-code drift check:

• make generated-code-check runs tools/check-generated-capnp.sh.
• The script invokes the actual Cargo build-script path for capos-config and capos-kernel in an isolated target directory, so it checks the generated artifacts that those crates would include from OUT_DIR.
• The script verifies that each patched file still contains the capnpc anchor plus the local no_std patch imports, compares the two crate outputs byte-for-byte, and then compares both outputs against tools/generated/capos_capnp.rs.
• Any intentional schema/codegen/patch change must update the checked-in baseline in the same review, making generated output drift review-visible.
• make check runs fmt-check plus generated-code-check for a single local or CI entry point.
• Current pinned compiler source is capnproto-c++-1.2.0.tar.gz from https://capnproto.org/ with SHA-256 ed00e44ecbbda5186bc78a41ba64a8dc4a861b5f8d4e822959b0144ae6fd42ef. The checked-in tools/generated/capos_capnp.rs baseline must be regenerated with that compiler when schema or codegen behavior intentionally changes. The current pinned baseline SHA-256 is 224b4ec2296f800bd577b75cfbd679ebb78e7aa2f813ad9893061f4867c9dd3d.

Remaining gaps for S.10.3:

• The no_std patching logic still lives in both build scripts. The baseline and pairwise output comparison catch divergent results, but a future cleanup could move the patch helper into shared source to reduce duplication.

Cargo Build Scripts

Build scripts currently do these trusted operations:

The linker build scripts derive CARGO_MANIFEST_DIR from Cargo and only emit link arguments plus rerun directives. The capnp build scripts read and rewrite generated code under OUT_DIR. None of these scripts fetch network resources.

S.10.2 coverage: make generated-code-check exercises both capnp build scripts through Cargo, validates the patched generated files, and fails if the two crate outputs drift apart or no longer match the checked-in generated baseline.

Manifest, Embedded Binaries, and Downloaded Artifacts

system.cue declares named binaries and services. Makefile:54-55 builds manifest.bin by running tools/mkmanifest on the host. mkmanifest runs:

1. Resolve the clone-shared pinned CUE compiler from git state, reject missing or mismatched CAPOS_CUE, check cue version v0.16.0, then run cue export system.cue --out json (tools/mkmanifest/src/main.rs:65-128).
2. JSON-to-CueValue conversion and manifest validation (tools/mkmanifest/src/main.rs:13-23).
3. Binary embedding from relative paths (tools/mkmanifest/src/lib.rs:135-180).
4. Binary-reference validation and Cap’n Proto serialization (tools/mkmanifest/src/main.rs:37-49).

Path handling rejects absolute paths, parent traversal, non-normal components, and canonicalized paths that escape the manifest directory (tools/mkmanifest/src/lib.rs:182-217). The generated manifest.bin is copied into the ISO as /boot/manifest.bin (Makefile:117) and loaded by Limine via limine.conf:5.

Downloaded or generated artifacts in the current build:

Remaining gaps for S.10.2/S.10.3:

• Decide whether CI should record or compare hashes for manifest.bin, embedded ELF payloads, or the final ISO for reproducible-build tracking.
• Pin or record xorriso, qemu-system-x86_64, OVMF firmware, and other host tools used by build and boot verification with the same strictness as capnp and cue.
• Decide whether CI should record the pinned cue export JSON or final manifest.bin bytes if manifest reproducibility becomes release-critical.

Host Tools

Current local host versions observed during this inventory:

These are environment observations, not repository pins. make run-uefi also trusts /usr/share/edk2/x64/OVMF.4m.fd (Makefile:82-83) without a checksum.

Remaining gap for S.10.3: decide the minimum supported host tool versions and whether they are enforced by CI, a container/devshell, or explicit preflight checks.

Inventory Method

This inventory is based on source inspection, Cargo metadata, lockfile checks, and local host-tool version queries. Local host-tool versions are observations, not repository pins; the tables above distinguish enforced pins from observed environment state.

Useful commands for refreshing the inventory:

• git status --short --branch
• rg -n "S\\.10|trusted|supply|Limine|limine|capnp|capnpc|QEMU|qemu|download|curl|git clone|wget|build\\.rs|rust-toolchain|Cargo\\.lock" ...
• rg --files
• cargo metadata --locked --format-version 1 --no-deps
• rg -n '^name = |^version = |^checksum = ' Cargo.lock init/Cargo.lock demos/Cargo.lock tools/mkmanifest/Cargo.lock fuzz/Cargo.lock
• command -v rustc cargo capnp cue qemu-system-x86_64 xorriso sha256sum git make
• rustc -Vv, cargo -V, capnp --version, cue version, qemu-system-x86_64 --version, xorriso -version, make --version, git --version