docs: fix the CSRF-exempt list and describe how secret_env actually reaches a container

**COMMANDS.md** named six CSRF-exempt read-only methods, two of which
(`bitcoin.getinfo`, `monitoring.current`) are not exempt — a client trusting the
doc would send them with the cookie alone and get rejected. The real set is
twelve (`api/rpc/mod.rs:326-340`); listed all of them and said plainly that
everything else needs the header. The rest of the doc verified clean: the 480 /
200 / 160-char caps, the four `assistant_*` config keys, both default model ids,
`is_sender_allowed`, `strip_archy_trigger` / `run_node_cmd`, the three
unauthenticated HTTP endpoints, and `auth.login.totp` all match the code.

**secrets.md** said `secret_env` "sets `<key>` in the container's environment",
which reads as a plain `-e KEY=value` and undersells the design. It isn't:
resolved pairs are registered as podman secrets named
`archy-env-<app-id>-<key>` and referenced by name, precisely so the value stays
out of `podman inspect` and out of plaintext `Environment=` lines in Quadlet
units. Also documented the interpolation-taint rule — a plain `environment`
entry that expands `${SECRET}` (BTCPay's connection strings) is itself treated
as secret-bearing rather than left in the clear, which is what makes it safe to
build connection strings from secrets.

Everything else in secrets.md verified against `container/secrets.rs`: the four
kinds and their file shapes, the bare-filename rule, the every-tick idempotent
`ensure_generated_secrets`, and the atomic 0600 temp-fsync-rename writer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
archipelago
2026-08-07 20:51:53 -04:00
co-authored by Claude Opus 5
parent 7adc3260a6
commit 2c53a7d77f
2 changed files with 17 additions and 3 deletions
+12 -2
View File
@@ -60,8 +60,18 @@ container:
```
At apply time the orchestrator reads `/var/lib/archipelago/secrets/<secret_file>`
and sets `<key>` in the container's environment to its contents. The value is
never written into the manifest, the Quadlet unit, or any log line.
and makes it available in the container as `<key>`. It does **not** do this by
adding `KEY=value` to the environment — that value would show up in
`podman inspect` output and, on the Quadlet path, as a plaintext `Environment=`
line in a unit file on disk. Instead the resolved pairs are registered as podman
secrets named `archy-env-<app-id>-<key>` and referenced by name, so the value
never lands in the manifest, a unit file, `podman inspect`, or a log line.
**Interpolation taints.** A plain `environment` entry that interpolates a secret
— e.g. BTCPay's `ConnectionString=...Password=${BTCPAY_DB_PASS}` — is treated as
secret-bearing itself and travels the same protected path, rather than being
left in the clear because it was declared under `environment`. So you can build
connection strings from secrets without leaking them.
## How materialisation works