bingshuo/hololake-system-architecture
Watch
1
0
Fork
You've already forked hololake-system-architecture
 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity
hololake-system-architecture/product-source/hololake-native-desktop/server/release-broadcast/README.md

3.1 KiB
Raw Blame History

HoloLake release broadcast candidate

This is the HoloLake-owned, loopback-only origin for signed update broadcasts. It has no upstream software feed and never uploads or activates a release.

Without ACTIVE.json, /health reports EMPTY_FAIL_CLOSED and /latest.json returns HTTP 204, the updater protocol's explicit no-update result. An active release is accepted only when the human activation record, immutable broadcast, pipeline receipt, package bytes, Developer ID receipt, and Apple notarization receipt form one exact evidence chain. Invalid evidence locks the whole release endpoint until an operator fixes the evidence and explicitly restarts the service.

The service listens only on 127.0.0.1. The public HTTPS path is carried by a dedicated, port-forwarding-only identity from JD-FD-PRIMARY to BS-GZ-006 and currently returns the origin's empty fail-closed 204 response. Artifact upload, activation, and desktop rollout remain independent deployment gates.

The registered public namespace is /hololake/releases. The loopback origin accepts the manifest at both its operator health-check path /latest.json and the public updater path /hololake/releases/latest.json; release package URLs must remain under that same public prefix. The front-door proxy must therefore preserve the full request URI. The registered BS-GZ-006 loopback tunnel port is 19440; it is not a public listener.

render-front-door.mjs --loopback-port PORT renders the bounded Nginx location. It refuses an omitted port, preserves the full public request path by leaving proxy_pass without a URI suffix, accepts only GET and HEAD, forwards no request body, and strips authorization, cookies, and client forwarding headers. Rendering is not deployment; Nginx validation, transactional install, public certificate/readback, and a separate server receipt remain required.

operator.mjs supplies the separate, root-operated verification and activation boundary. verify reconstructs a private candidate tree and accepts it only when the broadcast, pipeline receipt, package bytes, Developer ID receipt, Apple notarization receipt, and exact human approval all agree. activate additionally requires the operator to repeat the expected release id, version, source commit, and broadcast SHA-256. It copies only referenced immutable artifacts, commits ACTIVE.json atomically, and reports that an explicit service restart is still required. It never uploads, activates, or restarts on its own.

node operator.mjs verify \
  --source /secure/release/out/0.2.0 \
  --human-approval /secure/approvals/0.2.0.json

sudo node operator.mjs activate \
  --source /secure/release/out/0.2.0 \
  --human-approval /secure/approvals/0.2.0.json \
  --state-root /var/lib/guanghu/hololake-release-broadcast \
  --expect-release-id GH-HOLOLAKE-RELEASE-0.2.0 \
  --expect-version 0.2.0 \
  --expect-source-commit 0000000000000000000000000000000000000000 \
  --expect-broadcast-sha256 0000000000000000000000000000000000000000000000000000000000000000

The zeros above are placeholders, not deployable values. A real activation must use the exact facts printed by verify and a separately issued human approval.