halkyon/deploy/allowed-signers

# The keys whose signatures deploy/redeploy.sh accepts on main: OpenPGP primary key
# fingerprints, one per line. The deployed checkout's copy decides, so a new key comes in
# through a commit signed by a key already listed here, and its public key goes into
# deploy's GPG keyring on the server (gpg --import).
B172B9ED76A32EBCABA24A9F07F6FCF405488B64
ci: check every push on sahaquiel and deploy a green main Pushes to main were deployed by hand. Now Forgejo Actions runs tool/check.sh on every push, and a green main deploys learn.halkyon.eu by itself. The runner (forgejo-runner v13.1.0) runs on sahaquiel as the unprivileged user `runner`, with jobs directly on the host: containers would take Docker access, which is root on the production server, and Forgejo warns that host jobs have no isolation from the runner's user. So its systemd unit (deploy/runner/forgejo-runner.service) provides it: /home and the Docker socket invisible, Docker's container networks unreachable, no capabilities, two cores and 3 GB at most, lowest priority. It is registered to this repository only, with the UUID and token of Forgejo's "Create new runner" (the old `register` is deprecated); the token reaches it as a systemd credential. The configuration (deploy/runner/config.yml) was dry-run against v13.1.0, the unit rates 1.8 in `systemd-analyze security`. CI runs on pushes only: a pull request from a fork would run its code on the production server. The deploy job calls deploy/redeploy.sh as `deploy`, through a key that authorized_keys pins to that script and to connections from sahaquiel itself. The script deploys the commit CI checked while it is still main's tip, as a fast-forward, only if every new commit is signed by a key in deploy/allowed-signers (as the deployed checkout lists them), after dumping the database (the last ten are kept), and fails unless the server answers afterwards; a failure puts the checkout back. Tested against the local stack: refusals of a malformed argument, a stale commit, a forged unsigned commit and a non-fast-forward, a real deploy with its dump, a repeat, and a failed build. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me> 2026-09-30 21:49:04 +02:00			`# The keys whose signatures deploy/redeploy.sh accepts on main: OpenPGP primary key`
			`# fingerprints, one per line. The deployed checkout's copy decides, so a new key comes in`
			`# through a commit signed by a key already listed here, and its public key goes into`
chore: the servers are named by the domain they serve Files called the servers by their own host names, which are the operator's and say nothing a reader needs. They now say which domain a server serves: learn.halkyon.eu's server (the instance and its CI runner), the halkyon.app server (Forgejo and the F-Droid repository). Two names are settings rather than words. CI's runner label becomes `instance` (`runs-on: instance`, `labels: ["instance:host"]`): the runner reads its installed copy of deploy/runner/config.yml, so jobs wait in the queue until that copy is updated and the runner restarted. The SSH aliases the scripts and docs use become `learn-deploy` and `fdroid-upload`. AGENTS.md says to keep it so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me> 2026-10-13 23:11:40 +02:00			`# deploy's GPG keyring on the server (gpg --import).`
ci: check every push on sahaquiel and deploy a green main Pushes to main were deployed by hand. Now Forgejo Actions runs tool/check.sh on every push, and a green main deploys learn.halkyon.eu by itself. The runner (forgejo-runner v13.1.0) runs on sahaquiel as the unprivileged user `runner`, with jobs directly on the host: containers would take Docker access, which is root on the production server, and Forgejo warns that host jobs have no isolation from the runner's user. So its systemd unit (deploy/runner/forgejo-runner.service) provides it: /home and the Docker socket invisible, Docker's container networks unreachable, no capabilities, two cores and 3 GB at most, lowest priority. It is registered to this repository only, with the UUID and token of Forgejo's "Create new runner" (the old `register` is deprecated); the token reaches it as a systemd credential. The configuration (deploy/runner/config.yml) was dry-run against v13.1.0, the unit rates 1.8 in `systemd-analyze security`. CI runs on pushes only: a pull request from a fork would run its code on the production server. The deploy job calls deploy/redeploy.sh as `deploy`, through a key that authorized_keys pins to that script and to connections from sahaquiel itself. The script deploys the commit CI checked while it is still main's tip, as a fast-forward, only if every new commit is signed by a key in deploy/allowed-signers (as the deployed checkout lists them), after dumping the database (the last ten are kept), and fails unless the server answers afterwards; a failure puts the checkout back. Tested against the local stack: refusals of a malformed argument, a stale commit, a forged unsigned commit and a non-fast-forward, a real deploy with its dump, a repeat, and a failed build. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me> 2026-09-30 21:49:04 +02:00			`B172B9ED76A32EBCABA24A9F07F6FCF405488B64`