Signed software releases

Building and approving#

• An isolated builder service, running as its own unprivileged account, checks out each product from a read-only source, runs the product's tests and prepares a candidate. It cannot sign or publish.
• An authorised SENTRA approver reviews the candidate's test results and release notes and approves it with a fresh two-factor code. With four-eyes on, a second approver must approve too.
• Only then does the Licensing Authority's vault sign the product's release list with the release key, which the root key certifies.
• A published version can never be replaced; a bad release can be withdrawn, which re-signs the list so that no system offers or installs it again.

What every system checks#

root key (built in)
  └─ release-key certificate (signed by the root; valid dates; allowed products)
       └─ release list (index.json, signed by the release key, checked over its exact bytes)
            └─ the package's SHA-256 and the file list's SHA-256
                 └─ every file's SHA-256

Nothing is installed unless every link checks out. SENTRA VIEW passes the signed proof down to each GUARD, which checks every file again, and each GUARD to its ATS and NTS boxes, which check again: no layer has to trust the one above it.

The release server holds no secrets#

updates.sentra-ai.com only serves signed files. Someone who controlled it, or the network path to it, could at most delay updates; they could not make any SENTRA system install code SENTRA did not approve. A second release server can therefore be added for availability without adding any trust.

Customer control#

Customer administrators decide when an offered update is installed (now, scheduled, or skipped), unless they choose automatic updates. Fleet operators can lock GUARDs and nodes to signed releases only.