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

admin_emi commented

2026-08-01 15:51:46 +00:00

Owner

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:381-423) 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.

Added to both renderers with identical logic (verified by diffing the blocks with comments stripped). 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.

Verification

Unit-tested the validator against 10 inputs — all three valid shapes, role-omitted, unset, invalid JSON, non-email, duplicate address, empty object, scalar — all behave as intended.

End to end against the live vault with verify-centralis-render.sh prod:

9 keys quoted
CENTRALIS_TOKENS parses: 2 subject(s) — emi, jin
9 keys survive `set -a; . <file>` byte-for-byte
VERDICT: PASS — the render is value-identical to the live file
compose model : IDENTICAL (docker compose config digests match)

That is also the first time the Centralis renderer has been run against a live vault since it was merged.

`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:381-423`) **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. Added to **both** renderers with identical logic (verified by diffing the blocks with comments stripped). 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. ### Verification Unit-tested the validator against 10 inputs — all three valid shapes, role-omitted, unset, invalid JSON, non-email, duplicate address, empty object, scalar — all behave as intended. End to end against the live vault with `verify-centralis-render.sh prod`: ``` 9 keys quoted CENTRALIS_TOKENS parses: 2 subject(s) — emi, jin 9 keys survive `set -a; . <file>` byte-for-byte VERDICT: PASS — the render is value-identical to the live file compose model : IDENTICAL (docker compose config digests match) ``` That is also the first time the Centralis renderer has been run against a live vault since it was merged.

admin_emi added 1 commit 2026-08-01 15:51:48 +00:00

secrets: validate CENTRALIS_TEAM at render time, like CENTRALIS_TOKENS

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

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

2194aaa1c4

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.

admin_emi force-pushed feat/centralis-team-validation from 2194aaa1c4 to 7b3ea69ef9

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

Compare