[Umbrella] Implement the runtime trust-generation accept path with the `epoch` floor

[sehkone]

Implement the runtime trust-generation accept path with the epoch floor

Summary

Keys rotate, keys get revoked and builds get withdrawn long after the one-shot installer is gone. A new release-trust generation therefore has to be deliverable at runtime, over the same package channel every other package rides, targeting the reserved trust package-id. This effort adds the host side of that: the entry points a root daemon calls to accept a delivered generation, the monotonic epoch floor that stops an old but validly signed generation from being replayed to restore a revoked key or drop a withdrawn build, and the two recovery doors for hosts the ordinary path cannot serve.

The work splits along the line the trust basis itself draws. One half admits a generation against the active generation's key set — the ordinary runtime channel, where the floor, the byte-identical no-op and the chain rules live. The other half admits a generation under the anchors the delivered document itself carries — self-admission, the same cryptographic act the installer's seed performs, reached over different channels for a host that has fallen past the control plane's retention floor and for a host that has no generation at all. The two halves share a tree, a module and an error type but almost no logic; each declares the refusals its own path raises.

Both land in this crate rather than in the installer's repository. The caller these paths are built for is a root daemon that will link this crate directly and can construct no installer type, and there must be exactly one implementation of the floor. That daemon has not linked the crate yet — this API is part of what it will link for — so nothing consumes these entry points on the day they merge, and their shape is settled here rather than negotiated later. Neither half has a counterpart in the installer's repository, and neither requires a pin bump anywhere else.

Children

• Add the runtime trust-generation accept path with the epoch floor #50
• Add the re-bootstrap and no-prior-generation trust-generation entry points #51

The first child is the critical path. It establishes the runtime channel's floor semantics and the canonical-generation precondition every runtime entry point runs first, and it supplies the accept path that the second child's central assertion — that re-bootstrap succeeds where ordinary accept fails on the same inputs — is written against, without which that test does not compile. Both children also edit the same module heavily and add variants to the same public error enum, so sequencing them forfeits no parallelism that running them together would have won.

Schedule risk is concentrated in the second child, whose surface is the larger of the two: a factoring of the existing self-admission sequence with a byte-identical regression bar over two callers that already ship, a new authorization type with a deliberately hostile constructibility contract, a host-state gate with a fail-closed read, and a new declared file location with two resolutions. Landing it after the first child keeps that risk separate from the floor's.

Shared background

origin/main already carries the release-trust tree and everything the container format needs; this effort rebuilds none of it.

src/release_trust.rs owns the tree at the directory Layout::release_trust_dir() resolves — an active symlink, gen-<n>/ generation directories, and inside each generation three files: the delivered container as generation.pkg, the trust-set.json member, and an epoch record. src/generation.rs is the generalized activation engine underneath it, which stages a material set, repoints active atomically and prunes the superseded generation. Its failure contract has three outcomes rather than two — nothing published, though a gen-<n>.tmp may survive an I/O fault mid-staging; finalised but not live, leaving a complete gen-<n>/ that nothing points at; and live-but-unpruned after the swap — so what readers resolve is unchanged in the first two and changed in the third. Neither child alters that contract, and neither asserts an exact tree state over a failure inside it. src/verify.rs is the shared verifier and already implements the whole taxonomy — signature, target, manifest-format floor, revocation, withdrawal and the strictly-greater epoch comparison — against a caller-injected TrustSet. src/trust_set.rs holds the document, its refusing reader, and the provisional permissive decode a self-admission needs before anything has authenticated the bytes.

Every entry point in the release-trust module takes the already-resolved tree root as root: &Path, and paths into that tree are resolved from the root by helpers that each join one declared basename. Nothing in this effort takes a Layout: the caller is a daemon that holds a root, not a namespace, and a root cannot be walked back up to the namespace it came from.

Refusals on these paths are ReleaseTrustError variants in src/release_trust.rs. roxyd_trust::TrustError belongs to the mTLS material module — a different concern on a different tree — and gains nothing here.

The effort ends at the API. The wire handler, the delivery channel and the transport that carries a generation to a host are elsewhere, as are the control plane's fan-out, its ledger and its retention window, and as is minting or signing a generation at all.

Execution order

Issues in the same wave have no unmet dependencies among these children and can run in parallel.

• Wave 1: Add the runtime trust-generation accept path with the epoch floor #50
• Wave 2: Add the re-bootstrap and no-prior-generation trust-generation entry points #51

graph TD
  issue50["#50 Add the runtime trust-generation accept path with the `epoch` floor [phase: unphased]"]
  issue51["#51 Add the re-bootstrap and no-prior-generation trust-generation entry points [phase: unphased]"]
  issue50 --> issue51

Loading

[sehkone]

Both children have landed, so this umbrella is complete.

child	PR	squash
#50 Add the runtime trust-generation accept path with the epoch floor	#52	9a9091e3aa
#51 Add the re-bootstrap and no-prior-generation trust-generation entry points	#53	29ac55d7

Verified against main at 29ac55d: all five commands CI runs pass locally — cargo fmt -- --check --config group_imports=StdExternalCrate, both -D warnings clippy invocations, and cargo test with and without test-support, at 422 tests, up from 372 when #6 closed.

This issue's original body — its scope, its 27 acceptance criteria and its test plan — was replaced when the tree was filed and now reads as an umbrella; the prior text remains readable through userContentEdits. The two children carry 57 acceptance criteria between them and every one of the original 27 has a home among them. Checked point by point against the code, with nothing implemented differently from what the original text asked for.

Spot checks worth recording, since they are the properties that would be expensive to rediscover:

• The entry-point set is closed at five, as the original required: read_generation_state, accept_generation, accept_generation_chain, rebootstrap_generation, bootstrap_from_join_material. No mode field, no skip flag, no builder default that relaxes a check.
• The no-pin-while-required refusal is its own variant, distinct from the pin mismatch: FingerprintPinRequired and FingerprintPinMismatch. ReleaseTrustError went from 19 variants to 25.
• The pin marker is probed with symlink_metadata, so a dangling symlink reads as set rather than absent, and only NotFound means unset. Pinned by a_dangling_symlink_at_the_marker_path_reads_as_set.
• RebootstrapAuthorization derives only Debug, Clone, Copy — no Default, no Deserialize, no conversion from any wire type — holds its asserted epoch in a private field, and is built solely through asserting_last_confirmed_epoch.

One test deserves a specific mention. The original required that no path here reach #6's install-time replace_generation, and that it be asserted by a test rather than by review. no_runtime_entry_point_reaches_the_install_time_replace_door does it by observing the callee — a #[cfg(test)] recorder inside replace_generation itself — so a helper that reached the door would be caught exactly as a direct call would, without anyone having to enumerate the helpers. It then drives every runtime entry point across success, every refusal shape and every tree shape, and finishes with a negative control that calls the door directly to prove the recorder fires at all.

aicers/deploy-core has no open issues after this.

Downstream: aicers/bootler#196 tracks this issue and aicers/bootler#197 is the sub-umbrella above it. Per that repository's docs/rfcs/0004-deploy-core-landing.md §3 this is the one part of the effort with no bootler half and no pin bump, so both close with this one and no bootler work follows from it.