Why every release is signed, and what the updater checks
KLYRN VM refuses an update whose signature does not verify, runs the new binary before switching to it, and keeps the one it replaced.
A panel that updates every server it runs on is a target. KLYRN VM's update path is built so that a tampered or broken release cannot take a controller down.
Four checks before anything changes
- The release manifest is verified against a public key compiled into the binary. A manifest that does not verify is refused.
- The new binary is downloaded beside the one in use, and its checksum is compared with the signed manifest.
- The candidate is run and must report its own version. A binary that cannot start never becomes the running one.
- The binary it replaces is kept, so a rollback is one step.
Compute nodes update the same way, in a rollout the controller drives node by node. A controller restarted in the middle of a rollout reads its plan from the database and carries on where it stopped.
The install command performs the same verification before the first binary runs. See install and updates.