docs(1408): psk_file reviewed and CLOSED — its one argument was false

[dc0sk]

Review artifact only. No code, no config field. #1408 is closed; this is the record of why, with a checkable reopen condition.

The load-bearing sentence was false

I claimed LoadCredential= delivers a path, "so it needs exactly this field and nothing else". It does not — a systemd credential composes with the existing env reader today, with zero code:

ExecStart=/bin/sh -c 'OPENPULSE_CONTROL_PSK=$(cat "$CREDENTIALS_DIRECTORY/control-psk") exec …'

So psk_file does not unlock systemd credentials; it removes a one-line wrapper. That was the proposal's sole claimed new capability.

And there is no systemd deployment here

Verified independently: 0 .service/.timer/.socket files and no packaging directory; every launch is nohup … & over ssh as an interactive user (6 scripts); deploy-rpi-pair.sh rsyncs binaries to ~/bin and stops; control binds 127.0.0.1. Nothing in the repo sets OPENPULSE_CONTROL_PSK — control: the same filter finds the reader in 3 Rust files. That confirms #1234's "no deployment has ever set the PSK" from a second direction.

Two further qualifiers: the daemon needs the operator's PipeWire session, so the natural unit is a user unit — and encrypted credentials for per-user managers arrived only in systemd v256 (trixie yes, the bookworm legacy Pi image no). And a Pi has no TPM2, so "encrypted at rest" is the host key on the same SD card: protection against a non-root same-host reader, which 0600 already gives, and none against card theft — beside an Ed25519 station seed that is plaintext at 0600.

My "same security tier" claim holds — and that is what closes it

Relative to the keystore it is the same tier with moving parts removed. Relative to env it is the same tier with moving parts added: a path, a permission check, a precedence rule. The two real deltas are small and neither is a capability — env is inherited by children (the daemon's only spawn is nvidia-smi per GPU tick, absent on a Pi), and validate_owner_only would refuse a 0644 file where systemd accepts a 0644 EnvironmentFile silently.

The "~20 lines" estimate was the parser branch only

Both config templates' comments become false; inert_psk_key_id_warning says "OPENPULSE_CONTROL_PSK only" and a test asserts that substring; the fail-closed error names only the env var; the parser embeds the variable name in its error strings; plus both-present refusal, missing-path error, empty-string-unset, four places in the book, and tests — load_control_psk has zero tests today, so the file path needs a seam. Realistically 150–250 lines across ~8 files.

Recorded for a future attempt

If it is ever built: refuse on both-present — but not for #1234's reason, which does not transfer. Under file-wins a stale export is inert, so the dangerous rotation pre-image exists only under env-wins; refusal is right because it is the cheapest rule and legible at start. A set path to a missing file must be Err, never Ok(None). psk_file = "" means unset.

Reopen condition: a systemd-managed deployment exists in this repo (a unit file or packaging target) and a non-loopback bind is in use — and even then, try the zero-code ExecStart wrapper first.

Verification

review lint ok · doc frontmatter ok · doc stamps ok · trace check ok. Docs only.

Verification-objective: a proposal must be judged against what the deployment actually does, so that a capability claimed for a mechanism nobody runs is not mistaken for a reason to add code.

Review: docs/dev/reviews/review-1408-psk-file.md

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6