secrets: validate CENTRALIS_TEAM at render time, like CENTRALIS_TOKENS #144

Open

admin_emi wants to merge 1 commit from feat/centralis-team-validation into dev

Author	SHA1	Message	Date
Emi Griffith	7b3ea69ef9	secrets: validate CENTRALIS_TEAM at render time, like CENTRALIS_TOKENS All checks were successful PR build (required check) / changes (pull_request) Successful in 6s Details secrets-guard / encrypted (pull_request) Successful in 5s Details PR build (required check) / build-backend (pull_request) Has been skipped Details shell-lint / shellcheck (pull_request) Successful in 7s Details PR build (required check) / build-frontend (pull_request) Has been skipped Details PR build (required check) / validate-observability (pull_request) Has been skipped Details PR build (required check) / gate (pull_request) Successful in 2s Details CENTRALIS_TOKENS has a parse-and-prove check in both renderers because it is JSON, full of double quotes, living in a file bash expands, and because Centralis fails closed on it. CENTRALIS_TEAM is the same kind of value with none of the same guard. It is the allowlist for Google sign-in. Centralis' buildOAuth() requires a Google client AND at least one team member, so an empty or malformed team does not fail loudly -- it turns OAuth off and leaves the server bearer-token-only, which looks exactly like never having configured it. The sharper failure is a partial one. parseTeam() (centralis src/config.ts) SKIPS an unparseable entry with a console.error and carries on, so an address with a typo'd domain drops exactly one person, behind a log line on a container start nobody watches. Entries parseTeam would skip are therefore refused here, where a human is reading the output. Accepts all three shapes parseTeam accepts -- email->role, email->object, and an array of objects -- and matches its case-insensitive duplicate detection. Rejects invalid JSON, a non-object/array, an entry without an @, a duplicate address, and an empty team. Prints member addresses and roles on success, the same argument the adjacent CENTRALIS_TOKENS line makes for printing subjects: seeing the list is how an operator notices somebody is missing. Added to BOTH renderers with identical logic. The parity argument this migration rests on is that the two backends produce the same file; a validation present on only one side means one backend can write a file the other would have refused. Verified end to end against the live vault with verify-centralis-render.sh: 9 keys, 2 subjects, VERDICT PASS, compose model digests identical.	2026-08-01 15:57:57 +00:00

Author

SHA1

Message

Date

Emi Griffith

7b3ea69ef9

secrets: validate CENTRALIS_TEAM at render time, like CENTRALIS_TOKENS

PR build (required check) / changes (pull_request) Successful in 6s

Details

secrets-guard / encrypted (pull_request) Successful in 5s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

shell-lint / shellcheck (pull_request) Successful in 7s

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 2s

Details

CENTRALIS_TOKENS has a parse-and-prove check in both renderers because it is
JSON, full of double quotes, living in a file bash expands, and because
Centralis fails closed on it. CENTRALIS_TEAM is the same kind of value with
none of the same guard.

It is the allowlist for Google sign-in. Centralis' buildOAuth() requires a
Google client AND at least one team member, so an empty or malformed team does
not fail loudly -- it turns OAuth off and leaves the server bearer-token-only,
which looks exactly like never having configured it.

The sharper failure is a partial one. parseTeam() (centralis src/config.ts)
SKIPS an unparseable entry with a console.error and carries on, so an address
with a typo'd domain drops exactly one person, behind a log line on a container
start nobody watches. Entries parseTeam would skip are therefore refused here,
where a human is reading the output.

Accepts all three shapes parseTeam accepts -- email->role, email->object, and
an array of objects -- and matches its case-insensitive duplicate detection.
Rejects invalid JSON, a non-object/array, an entry without an @, a duplicate
address, and an empty team. Prints member addresses and roles on success, the
same argument the adjacent CENTRALIS_TOKENS line makes for printing subjects:
seeing the list is how an operator notices somebody is missing.

Added to BOTH renderers with identical logic. The parity argument this
migration rests on is that the two backends produce the same file; a validation
present on only one side means one backend can write a file the other would
have refused.

Verified end to end against the live vault with verify-centralis-render.sh:
9 keys, 2 subjects, VERDICT PASS, compose model digests identical.

2026-08-01 15:57:57 +00:00