Build Service

Role

The build service is a general-purpose, org-available build environment. Any authenticated org member (human or agent) can submit a build manifest (source + instructions) and receive back build artifacts. The build service compiles in a controlled, reproducible environment and signs the output so the org knows: "this binary was built from this source in a controlled environment."

The build service runs as a tier 2 org container (or tier 3 VM for builds that need stronger isolation). It's available on demand -- the reconciler places it on a node with sufficient resources.

What It Does

General-purpose builds:

Accept a build manifest: source directory/repo + build instructions
Execute the build in an isolated environment (namespaces + cgroups for containers, full VM for untrusted source)
Return build artifacts to the submitter's scratch or org shard storage
Sign artifacts with the build service's key: the signature attests "this output was produced by the org's build service from this input"

FortrOS image builds (special case):

Compile the FortrOS Rust workspace (maintainer, reconciler, key service, etc.)
Apply the node overlay to the base rootfs
Pack into a generation UKI (kernel + initramfs via ruki-build)
Compute content hash (SHA-256)
Sign the generation UKI with the build service's attestation key

Optimized kernel builds:

Accept hardware probe output from a specific machine
Build a kernel with localyesconfig + CPU architecture flags
Different hardware = different generation images, all from the same service

Org service image builds:

Compile service binaries from source
Package as rootfs tarballs for tier 2 containers or disk images for tier 3 VMs
Sign with the build attestation key

Build Attestation

The build service signs everything it produces. The signature means:

"This artifact was built by the org's build service, from the provided source, in a controlled environment. The source hash is X, the output hash is Y, the build was executed at time Z."

This provides supply chain integrity:

Anyone on the org can verify a binary was built in the controlled environment, not compiled on someone's laptop
No need to decompile to verify provenance -- check the signature against the build service's public key (published in the org CRDT)
Reproducible builds: Given the same source + manifest, the build service produces the same output. A suspicious binary can be rebuilt from source and compared.

Who Signs What

Artifact	Signed by	What the signature means
Generation UKI	Build service	"Built from this source in controlled environment"
Org service image	Build service	"Built from this source in controlled environment"
User-submitted build	Build service	"Built from user's source in controlled environment"
UKI for Secure Boot enrollment	Org CA (via Provisioner or admin)	"Approved for boot on org hardware"

The build service's attestation key is separate from the org CA's signing key. The build service attests "I built this." The org CA attests "I approve this for deployment." These may be applied by different entities at different times (build service builds it, admin reviews it, org CA signs it for deployment).

Silo'd Design

The build service follows the silo'd principle:

Reads source and build inputs from its scratch (pre-staged by the orchestrator or submitted via the org's build API)
Writes artifacts to scratch
The orchestrator collects outputs and stores them in shard storage
The build service doesn't import FortrOS crates, doesn't call gossip or CRDT methods, doesn't access shard storage directly

A compromised build service can produce malicious artifacts, but: