Site: publish from CI after a push to main, over SSH with a key that can only run the refresh #79

New Issue

2026-10-07T12:26:12Z

twisla commented

2026-10-07 12:26:12 +00:00

The site is published by hand today: after a merge that changes it, the maintainer runs rororefresh.sh on the web server (see .gitea/workflows/site.yml: "Publishing is the maintainer's").

Wanted: the Site workflow does it. After a push to main that changes the site, and once the site has built and passed its checks, a job connects to the web server over SSH and runs the refresh.

Constraints

The credential the CI holds can run that one command and nothing else: no shell, no forwarding, no other command, whatever the client asks for.
The server's address, the user and the credential are Gitea secrets, not in the repository: it is public.
The server's host key is pinned (a secret too), so the job never connects to something else.
Never for a pull request, and never from a fork: only a push to main.
No firmware release needed: CI and server only.

To decide (design round in docs/milestones/W1.md)

An OpenSSH certificate (needs a CA, can expire) or a plain key with a forced command in authorized_keys.
Whether the command is a secret at all: with a forced command the server decides what runs, and what the client sends is ignored.
What a failed refresh does to the run, and two refreshes at once.

The site is published by hand today: after a merge that changes it, the maintainer runs `rororefresh.sh` on the web server (see `.gitea/workflows/site.yml`: "Publishing is the maintainer's"). **Wanted:** the Site workflow does it. After a push to `main` that changes the site, and once the site has built and passed its checks, a job connects to the web server over SSH and runs the refresh. **Constraints** - The credential the CI holds can run **that one command and nothing else**: no shell, no forwarding, no other command, whatever the client asks for. - The server's address, the user and the credential are **Gitea secrets**, not in the repository: it is public. - The server's host key is pinned (a secret too), so the job never connects to something else. - Never for a pull request, and never from a fork: only a push to `main`. - No firmware release needed: CI and server only. **To decide** (design round in docs/milestones/W1.md) - An OpenSSH certificate (needs a CA, can expire) or a plain key with a forced command in `authorized_keys`. - Whether the command is a secret at all: with a forced command the server decides what runs, and what the client sends is ignored. - What a failed refresh does to the run, and two refreshes at once.

twisla added this to the W1 Website milestone 2026-10-07 12:26:12 +00:00

twisla added the

concern/security area/website labels 2026-10-07 12:26:12 +00:00

twisla referenced this issue

2026-10-07 12:34:08 +00:00