[zibi-pplx]

Summary

Runtime releases can now arrive as a single executable or a tar.gz archive. Both use the existing bounded download, pinned payload and binary digests, ELF architecture checks, private staging and privileged publication. This supports static Cloud Hypervisor release packaging without changing Firecracker's installed layout.

Sources describe packaging; only catalog layout paths can become installation destinations. Missing, duplicate or foreign destination mappings fail before downloading. Durable job payloads and RPCs are unchanged. This PR does not add an installable Cloud Hypervisor release or enable its execution.

Validation

• Review regressions failed before the fix for repeated archive members and the redundant standalone payload copy; the final runtime-manager suite passed 63 tests (one upstream-network test ignored). Standalone staging now moves the synced executable, and production/test sources share layout-derived Firecracker packaging.
• Runtime-manager library suite with github: 63 passed; one upstream network test remains ignored.
• Linux arm64 all-target Clippy with github and warnings denied passed.
• Formatting and cargo arch passed; archcheck reports existing advisory size warnings.

New coverage exercises standalone downloads with transfer and binary mismatches, wrong architecture, size bounds, cancellation and invalid layouts. Existing Firecracker install, retry, delete and lost-response tests pass. No live runtime installation was performed.

Severity and risk

Severity does not apply: this adds a delivery format. Risk is in shared release staging; compiled pins and node-manager publication remain independent checks. No configuration or execution policy changes. Custom Rust release-source implementations must supply the new packaging description.

Stack

Cloud Hypervisor installation: #915 → #922 → #923 → #924, based on main after #921. This group ends at verified runtime installation; it does not enable sandbox execution or change Firecracker/E0 defaults. Upgrade node-manager and runtime-manager before requesting Cloud Hypervisor installs. The dependent execution stack begins at #925.

AI assistance: Codex drafted the implementation, tests and this description.

---

Stack created with Sapling. Best reviewed with ReviewStack.
Base: main; #921 is merged.

• runtime-manager: install pinned Cloud Hypervisor static releases #924
• runtime: route managed releases by runtime identity #923
• -> runtime-manager: verify standalone release executables #922
• runtime: recognize Cloud Hypervisor installations without snapshot claims #915

[the-gigi-pplx]

Review — 3 findings

Low

1. crates/libs/node/runtime/manager/server/src/installs/release.rs:430: Materialization::for_layout doesn't reject two layout binaries that map to the same archive member.
   The check filters members by binary only, so {bin/firecracker -> X, bin/jailer -> X} passes. The full download then runs before unpack fails. The description says invalid mappings fail before downloading, and this case doesn't. Also reject a repeated member.
2. crates/libs/node/runtime/manager/server/src/installs/release.rs:283 (materialize_executable): a standalone executable is copied a second time instead of being moved into place.
   release.download and the staged release directory are both under the same private staged_root, so set_permissions(0o755) plus rename into staged/<binary> would do the same job. The copy reads and writes the binary again and keeps two copies on disk until cleanup. It adds no verification, because release_digest re-hashes the installed file afterwards. It also adds guard branches (TooLarge, NotRegularFile, Truncated) that the tests can't reach: the download is already capped at the same max_bytes, and the TooLarge case fails in transfer::receive first.
3. crates/libs/node/runtime/manager/server/src/installs/github.rs:114: payload hard-codes ["firecracker", "jailer"] and the bin/ prefix, and FakeReleaseSource::payload (test_support.rs:326) is a verbatim copy.
   The old archive_member derived the list from FIRECRACKER_RELEASE_LAYOUT.binaries. Now a layout change makes every install fail with PayloadLayout until github.rs is edited by hand, and the fake hides any drift because it matches itself. Building the members from ReleaseLayout::of(RuntimeKind::Firecracker), or from one helper that both use, keeps a single source.

Verified against 328694f5f9e4a0a7745f6f94a4512d9b5d958d49. I checked whether a local write failure in materialize_executable (which maps to UnpackError::Read rather than Staging) fails the job permanently. It doesn't: local_read_failure treats any error carrying an OS errno as retriable, so ENOSPC or EIO still retries. CI is green apart from the advisory CodeQL run.

[the-gigi-pplx]

Approved. 3 non-blocking findings in the review comment above.

[zibi-pplx]

Addressed all three review notes in 5798f163c132.

• Reusing one archive member for multiple destination binaries is refused before download or staging.
• A standalone executable is moved within its private staging tree instead of copied a second time. Cancellation, no-follow regular-file checks, permissions/sync, final digest/ELF verification and independent privileged publication checks remain.
• Production and test Firecracker sources now use one packaging helper derived from the compiled release layout.

The duplicate-member and redundant-payload regression checks failed before the fix and passed afterward. At this PR, runtime-manager passed 63 tests (one external-network test ignored). The combined installation head also passed its affected suites and Linux ARM64 all-target Clippy. Live service-driven installation is still separate acceptance evidence.