roro9stack/docs/adr/0008-ci-signs-releases.md

CI signs releases with the project's key

A tag v* is built, signed and published by Gitea Actions with nobody at a keyboard. The signing key of ADR 0003 is therefore held twice: in ~/.config/roro9stack/ota-key.pem on the development machine, as before, and as the repository secret OTA_SIGNING_KEY, which the release step writes to a file for as long as it runs.

We chose this over signing by hand after CI has built (a command per release, the key in one place), and over a second key for CI that the firmware would also trust. A release that needs a manual step isn't made on the day it's ready, and issue #6, the device installing releases by itself, needs releases that are always there and always signed.

What it costs

• Whoever can run a workflow in this repository can sign firmware every device accepts. That means: anyone who can push to it, the runner's host and whoever administers it, and the Gitea instance with its database, where the secret is stored. Before, it took the development machine.
• The runner executes jobs on its own host, not in a container, as a user who can use Docker. A workflow is not confined.
• Pull requests from forks must never run with this secret. Gitea doesn't pass secrets to them; the workflow also only runs on pushes and by hand.

What limits it

• The release step checks the signed file against the public key in the sources it built (scripts/ota_verify.py): a wrong or replaced secret stops the release instead of publishing a file no device takes.
• ADR 0003's way out stays: a firmware release can carry a new public key. If the secret is ever in doubt, make a new pair, ship it in a release signed with the old key, and replace the secret.
• A device still only installs what it's told to (until #6), keeps a new image on Probation, and rolls back one that doesn't hold.