edge-control: install.sh seeds empty allowlist — every register breaks until admin populates it, with no install-time warning #1110

New issue

Closed

opened 2026-04-21 12:18:18 +00:00 by dev-bot · 1 comment

dev-bot commented

2026-04-21 12:18:18 +00:00

Collaborator

Problem

Follow-up to #833. The allowlist policy is correctly opt-in at the script layer (register.sh:109-112 allows all when the file is missing), but install.sh unconditionally seeds:

{"version":1,"allowed":{}}

This flips the effective default to deny all the moment install.sh runs, and the install summary does not call this out. Two failure modes:

Fresh install: an operator follows the README, runs install.sh, then attempts the documented disinto edge register myproject … smoke test. It fails with name not approved and there is no breadcrumb in the install output explaining why.
Upgrade onto a box with existing tunnels: the if [ ! -f "$ALLOWLIST_FILE" ] guard prevents clobbering, so this is safe only if the file already exists. The first upgrade run after this PR creates the empty allowlist; existing projects cannot re-register or rotate keys until admin retroactively allowlists each one.

Either case is a sharp footgun for a feature whose design goal is operator control, not operator surprise.

Proposal

In install.sh, when seeding allowlist.json:

log_warn clearly: "Allowlist seeded empty — no project can register until you add entries to ${ALLOWLIST_FILE}."
Add a paragraph to the install summary at the bottom showing the format and an example entry.
For upgrade safety, when the registry already has projects but the allowlist file does not, populate the allowlist with each existing project (no pubkey_fingerprint binding — preserves current behavior). Operator can tighten later.

Updating tools/edge-control/README.md with the allowlist workflow is part of the same change.

Acceptance

Fresh install prints a warning that registration is now gated on the allowlist.
Upgrade install on a box with existing registry entries auto-populates the allowlist with those project names (unbound), so existing tunnels keep working.
README documents the allowlist file format and how to add an entry.

Ported from Codeberg https://codeberg.org/johba/disinto/issues/841. Any #NNN references in the body above point to Codeberg issue numbers, not internal Forgejo numbers.

## Problem Follow-up to #833. The allowlist policy is correctly opt-in at the script layer (`register.sh:109-112` allows all when the file is missing), but `install.sh` unconditionally seeds: ```json {"version":1,"allowed":{}} ``` This flips the effective default to **deny all** the moment `install.sh` runs, and the install summary does not call this out. Two failure modes: 1. **Fresh install**: an operator follows the README, runs `install.sh`, then attempts the documented `disinto edge register myproject …` smoke test. It fails with `name not approved` and there is no breadcrumb in the install output explaining why. 2. **Upgrade onto a box with existing tunnels**: the `if [ ! -f "$ALLOWLIST_FILE" ]` guard prevents clobbering, so this is safe **only if** the file already exists. The first upgrade run after this PR creates the empty allowlist; existing projects cannot re-register or rotate keys until admin retroactively allowlists each one. Either case is a sharp footgun for a feature whose design goal is operator control, not operator surprise. ## Proposal In `install.sh`, when seeding `allowlist.json`: - `log_warn` clearly: `"Allowlist seeded empty — no project can register until you add entries to ${ALLOWLIST_FILE}."` - Add a paragraph to the install summary at the bottom showing the format and an example entry. - For upgrade safety, when the registry already has projects but the allowlist file does not, populate the allowlist with each existing project (no `pubkey_fingerprint` binding — preserves current behavior). Operator can tighten later. Updating `tools/edge-control/README.md` with the allowlist workflow is part of the same change. ## Acceptance - Fresh install prints a warning that registration is now gated on the allowlist. - Upgrade install on a box with existing registry entries auto-populates the allowlist with those project names (unbound), so existing tunnels keep working. - README documents the allowlist file format and how to add an entry. --- _Ported from Codeberg [https://codeberg.org/johba/disinto/issues/841](https://codeberg.org/johba/disinto/issues/841). Any `#NNN` references in the body above point to **Codeberg** issue numbers, not internal Forgejo numbers._