build(updates): package host updater artifacts

[mcharles-square]

Reviewable diff: +129/-2 across 5 files (excludes generated, test, and story files).

Summary

Packages the host updater into amd64 and arm64 deployment artifacts, publishes paired SHA-256 sidecars, and includes the hardened systemd unit plus narrow socket overlay required by the merged Fleet API bridge. The host binary is statically linked and verified before packaging, while release publication fails closed unless both architecture bundles and correctly bound checksums are present. These assets remain dormant until installer activation lands in #839.

Stack: Prerequisites #841 → #842 → #843 → #844 → #845 → #835 → #836 → #837 are merged. This is 4/6, and its diff is relative to main. Remaining descendants are #839 → #840: #839 installs and activates these assets, while #840 exposes one-click execution in the client.

How it works

The artifact workflow builds a CGO-disabled fleet-updater on each native architecture runner, rejects dynamically linked output, and verifies the embedded version. The server artifact carries that binary into the deployment bundle, where it is placed beside its systemd unit and a Compose overlay that exposes only the updater Unix-socket directory to fleet-api.

Before upload, the workflow verifies the bundle checksum and required updater paths. Stable/RC and nightly publishers then require both amd64 and arm64 pairs, regenerate the expected sidecar for each explicit bundle, and compare the complete digest-and-filename line before creating or updating a GitHub release. The service unit preserves the socket directory inode across stops and restarts, remains available through Docker outages, and gives an in-progress activation enough bounded time to drain safely.

flowchart LR
  B["Build static fleet-updater per architecture"] --> V["Verify ELF linkage and embedded version"]
  V --> S["Server artifact"]
  S --> D["Deployment bundle with unit and socket overlay"]
  D --> C["Verify required paths and SHA-256 sidecar"]
  C --> A["Upload amd64 and arm64 artifacts"]
  A --> P["Release/nightly publisher re-verifies each explicit pair"]

Loading

Areas of the code involved

Area / package / file	What changed	Why it matters for review
.github/workflows/proto-fleet-artifact-build.yml	Builds and validates the static updater, packages runtime assets, creates and checks sidecars	Review architecture naming, static-host portability, and the bundle contract
.github/workflows/release.yml, nightly-builds.yml	Require both architecture pairs and bind each sidecar to its explicit bundle before publication	Prevents partial, mismatched, or swapped release assets
deployment-files/docker-compose.updater.yaml	Mounts only the read-only updater socket directory into fleet-api	Security boundary preventing Docker-socket exposure
deployment-files/updater/proto-fleet-updater.service	Defines hardening, soft Docker ordering, bounded activation drain, and runtime-directory preservation	Review root-service permissions, recovery, and lifecycle behavior

Key technical decisions & trade-offs

• Build the host updater with CGO_ENABLED=0 and inspect its ELF headers, avoiding host glibc coupling at the cost of requiring pure-Go dependencies.
• Publish same-name .sha256 sidecars and compare their full content against each explicit amd64/arm64 bundle, keeping updater discovery deterministic and failing closed on partial or swapped artifacts.
• Treat SHA-256 sidecars as corruption and pairing checks, not independent publisher authentication; the GitHub release origin remains the trust anchor, while separately pinned release signing is intentionally out of scope.
• Use KillMode=mixed with a 50-minute stop bound so systemd signals the daemon first and preserves the updater's 45-minute activation safety window.
• Preserve the runtime directory across service stops and restarts so Docker's bind mount stays attached to the socket directory inode.
• Soft-order the updater after Docker instead of requiring Docker continuously; trigger-time preflight remains the authority for daemon readiness.
• Keep packaging separate from activation so this PR remains merge-safe; installation and enablement are isolated in feat(updates): bootstrap host updater installs #839.

Testing & validation

• go test ./cmd/fleet-updater ./internal/updater
• CGO-disabled build and embedded-version smoke check
• Host profile, HA profile, and complete non-interactive upgrade-safety harnesses
• Base plus updater Compose rendering
• Workflow/Compose YAML parsing, positive checksum-pair simulation, swapped-sidecar rejection, required-path checks, and git diff --check
• Pre-push client typecheck plus server and plugin lint hooks; final review-fix push reran server lint

End-to-end deployment artifact assembly is not run by PR CI; the reusable workflow executes only for release and nightly builds. The new in-workflow assertions make that explicit path fail before publication, but a real release/nightly run remains the integration coverage.

[github-actions]

🔐 Codex Security Review

Note: This is an automated security-focused code review generated by Codex.
It should be used as a supplementary check alongside human review.
False positives are possible - use your judgment.

Scope summary

• Reviewed pull request diff only (1eab1dbe2bed41b1c1b19ca125b507f70d3dfe39...82e774c5564219aa3ffb0ef1665acee25505c209, exact PR three-dot diff)
• Model: gpt-5.6-sol

💡 Click "edited" above to see previous reviews for this PR.

---

Review Summary

Overall Risk: NONE

Findings

No concrete security, correctness, or reliability findings were identified in the authoritative PR diff.

Notes

The reviewed changes package and publish the host updater, its systemd unit, Compose overlay, and filename-bound SHA-256 sidecars. No authentication, database, pool configuration, or protobuf changes are present.

---

_{Generated by Codex Security Review |
Triggered by: @mcharles-square |
Review workflow run}

[Copilot]

Pull request overview

This PR extends Proto Fleet’s release/nightly deployment artifacts to include the host updater payload and supporting runtime assets, along with SHA-256 checksum sidecars. It does so by updating the artifact-build workflow to build/validate/package the updater and by updating release/nightly publishing workflows to upload and verify the paired checksum files; the added systemd unit and Compose overlay are included in the deployment bundle but remain dormant until downstream installer activation.

Changes:

• Build and package a statically linked fleet-updater per architecture into the deployment bundle, and emit proto-fleet-<version>-<arch>.tar.gz.sha256 sidecars.
• Require and verify both amd64 and arm64 bundle+checksum pairs before publishing release/nightly assets.
• Add a hardened systemd unit and a narrow Docker Compose overlay that mounts only the updater socket directory read-only into fleet-api.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
deployment-files/updater/proto-fleet-updater.service	Adds the systemd service definition with hardening and bounded stop behavior for activation drain.
deployment-files/docker-compose.updater.yaml	Adds an overlay that injects the updater socket path env var and mounts only /run/proto-fleet-updater read-only into fleet-api.
.github/workflows/release.yml	Verifies deployment bundle checksum sidecars exist and pass, and uploads .sha256 assets alongside bundles.
.github/workflows/proto-fleet-artifact-build.yml	Builds/validates a static updater binary, packages it and its runtime assets into the deployment bundle, and generates/verifies checksum sidecars.
.github/workflows/nightly-builds.yml	Verifies deployment bundle checksum sidecars exist and pass, and publishes/uploads .sha256 assets alongside bundles for nightlies.