feat(update): signed offline packages, a signed release channel, and a support-access bridge

[tonyctalope]

Three changes the rented-appliance product needs, all of which belong here rather than in the private fleet layer because they are equally useful to a customer-run install.

1. A shared host↔pod directory for a support toggle

A second hostPath alongside the update one. No new port, no agent in the pod, same .path-unit idiom — it is the appliance-update contract reused verbatim.

The feature gate is the presence of a state.json with enrolled: true, not an env var. That is what lets this ship in the public chart unconditionally: a customer-run appliance mounts an empty directory and sees nothing. One values.yaml, no fork.

root:1001 0770, created before helm — kubelet's DirectoryOrCreate would otherwise create it root:root 0755 and the pod (uid 1001) could never write its triggers.

2. Signed offline update packages

Some customers cut outbound access entirely, so update.sh gains a second source. tools/build-offline-package.sh emits a self-sufficient bundle (chart, container images, scripts) from channel.json; the appliance verifies and stages it from a USB stick.

Verification is all-or-nothing: one signature over SHA256SUMS, which covers every file including the image tars. A coverage check rejects any file absent from that list — otherwise unsigned files could just be added alongside. Downgrades refused, min_from_version enforced as a floor.

Online and USB coexist. state.json moves to schema 2 with sources.{online,usb} and update_available resolved over the better of the two; fetch_manifest_online no longer dies. A network failure must never mask a valid USB package — the customers who cut the network are precisely the ones this path exists for, so that regression would defeat the feature silently.

3. A signed release channel

channel.json was signed nowhere. TLS proves we reached the right host; it says nothing about who wrote the file. Whoever controls MANIFEST_URL could tell every appliance "move to chart X, vLLM image Y". Separately, self_update() pulled update.sh — which then runs as root — over plain HTTPS.

Signing the manifest closes both with one key: channel.json gains updater_sha256, and the signature over the manifest covers it, so verifying the manifest transitively verifies the updater. Same primitive already in use (openssl pkeyutl -verify -rawin), no new dependency on the box.

Graduated so the public one-command install is untouched:

package-release.pub on the box	Manifest	update.sh refresh
absent (public default)	TLS-only, unchanged	TLS-only, unchanged
present	must be signed, else refused	must match the signed updater_sha256, else refused

⚠️ This PR cannot go green until the channel is signed

Both strict paths fail closed, which has a consequence worth stating plainly: forgetting to re-sign does not break the fleet, it stops it — every box quietly keeps its current version and nobody notices for weeks.

.github/workflows/channel-signature.yml exists to catch exactly that, and it will fail on this PR, because updater_sha256 is still empty and channel.json.sig does not exist. That is the workflow doing its job. To unblock, with the private key:

PACKAGE_PRIVATE_KEY=/path/to/package-release.key tools/sign-channel.sh
git add channel.json channel.json.sig && git commit

Also needed before merge: PACKAGE_PUBLIC_KEY_PEM as a repo variable (public half only, so not a secret) so the signature job actually verifies rather than warning.

Verification

tools/test-package-verify.sh — 23 assertions: a good package, a corrupted image tar, a foreign signature, a missing signature, a downgrade, an unmet min_from_version, a manifest tampered after signing, and the graduated no-key case. All scripts parse, including the ones generated inside heredocs (a bash -n of the parent does not cover those).

Not exercised yet: an end-to-end apply from a real USB stick on real hardware, and the reboot-with-nothing-attached gate. Both are physical.

🤖 Generated with Claude Code