secrets: vault dev and Centralis; render dev without common.yaml
Brings the last two credential stores under SOPS, so all three environments and
the control plane are managed the same way.
dev.yaml — dev was not "intentionally not wired in", it was broken
The vault README claimed dev had no real secrets. Both halves were false.
Dev needed secrets it did not have: thermograph-dev-daemon-1 has been in a crash
loop, restarting every ~60s with "neither THERMOGRAPH_INTERNAL_TOKEN nor
THERMOGRAPH_AUTH_SECRET is set; refusing to start" — so dev has had no Discord
gateway and no job timers. With THERMOGRAPH_BASE_URL unset the app also falls
back to https://thermograph.org, so dev's IndexNow pings and verification links
claimed to be prod. dev.yaml gives it its own generated AUTH_SECRET and a real
base URL, and 12 values total.
And dev already held production credentials: backend-deploy-dev.yml injects
S3_ACCESS_KEY/S3_SECRET_KEY into every dev deploy, and the only provisioned
keypair for that bucket is read-write — on the bucket holding prod's backups.
Dev does not need them; without bucket creds the lake service 503s and history
falls through to the archive. Those workflow lines still need removing.
dev renders dev.yaml ALONE, via THERMOGRAPH_SECRETS_SKIP_COMMON=1. Eleven of
common.yaml's sixteen values are live production credentials, the render is a
plaintext concatenation consumed through env_file:, and dev is the operator's
desktop AND the Forgejo runner executing unreviewed dev-branch code with the
docker socket mounted. An override in dev.yaml would not help — last-wins
governs consumers, but prod's value is still physically a line in the file.
Verified: current renderer leaks 28 lines onto dev including both S3 keypairs
and the VAPID private key; patched gives exactly 12 keys and no prod credential.
Beta's render is byte-identical either way.
centralis.prod.yaml — its own file, its own renderer
/etc/centralis.env was hand-edited, which is how a JSON registry got written
unquoted into a shell-sourced file tonight and silently collapsed three
identities to one. The renderer now owns the file.
It is service- AND environment-scoped, not folded into prod.yaml, because
/etc/thermograph.env is loaded into every container in the app stack. Folding
these in would put CENTRALIS_AUTH_TOKEN and CENTRALIS_TOKENS — which
authenticate an endpoint carrying run_on_host and sql_query(write) — into the
web backend's environment, turning a read-anything bug in the app into a
foothold on the control plane.
Quoting is guaranteed three ways rather than assumed. Critically, `sops -d
--output-type dotenv` emits values verbatim, so reusing the existing render path
would have reproduced tonight's bug exactly. The new function decrypts to JSON
and emits POSIX single-quoted assignments; it then sources its own output in a
clean shell and compares every value before touching /etc; and it refuses to
write unless CENTRALIS_TOKENS parses as a non-empty subject->token object after
sourcing. Tested against 16 hostile values including embedded quotes, newlines
and ;rm -rf /.
Value-identity proven, not asserted: rendered vs live compared as *effective*
values on prod (a textual diff would report a false difference, and would report
a false match if the vault had captured quote characters as part of the value),
plus both env files producing a byte-identical `docker compose config` digest.
9 keys, both token subjects preserved. Nothing deployed.
Note for later: /etc/thermograph.env is also shell-sourced, and survives on raw
dotenv only because none of its 32 current values contains a shell-special
character. It is one quoted secret away from the same bug.
Claude-Session: https://claude.ai/code/session_0182KTMrsTHJc3TcewCatJFY
2026-07-25 01:10:51 +00:00
|
|
|
CENTRALIS_AUTH_TOKEN: ENC[AES256_GCM,data:MoOrGKQoe0mFu0gk4koa0kX+I6SgcKSlDAh+motBvBy22kiWucumgrl9avCdepPP,iv:0Vn/8bld2+EZhcwEPepCnmn4ktXp63LJUrZ36uajZp8=,tag:cjM/AVlG21Mk36QB7TjfSw==,type:str]
|
|
|
|
|
CENTRALIS_FORGEJO_TOKEN: ENC[AES256_GCM,data:p1KKmZZHhB3IO9QdWe2CYuN+rho+lZf3aeADT2sxZrD5SYeA05O1VA==,iv:93QFRj4tNU44wo6eCn3oCGmLP2tm571S4IhVCXpSQk8=,tag:/yH0O5Y25RfLBmKOWWJkZQ==,type:str]
|
|
|
|
|
CENTRALIS_FORGEJO_URL: ENC[AES256_GCM,data:z3ZTFg/2F9ZeilolVXW2XlyjyQy9,iv:hX0lj94vXFG2lZCG3gykaE1oEjTsciREey7onyQgQsc=,tag:415VJUTErR9SG82mkS2jOg==,type:str]
|
|
|
|
|
CENTRALIS_LOKI_URL: ENC[AES256_GCM,data:cFzoMoUYhxEVIF/K8JArTB49GRAo,iv:BTgmKBOsTdnWcvYOww4Zve5dJd+ZnFnBbWv3y5V2Vi4=,tag:kZ6LKLIVXk4UOZYbAr483w==,type:str]
|
|
|
|
|
DISCORD_GUILD_ID: ENC[AES256_GCM,data:qUFkitxFHOZdA7h2xtNycUpdLA==,iv:RGfbTEdjWY4Wu9i8WQ0rAnDAwqLZZbTj/bsWavYEnjk=,tag:L2b2t+tLhGXpqmGcamBpNw==,type:str]
|
|
|
|
|
CENTRALIS_TRANSCRIPT_CHANNEL: ENC[AES256_GCM,data:poxdL903opQV5waTCnO4wM3eIg==,iv:m5VWJpWXb49qak0wYoS1/W7S22+BAl+AFzjTY2Zu0a8=,tag:8iILm7mM0S/9/aAG1DywkQ==,type:str]
|
|
|
|
|
CENTRALIS_VOICE_SUMMARY_CHANNEL: ENC[AES256_GCM,data:Ztvy9w8wpmEcROyRDJOosBJlWw==,iv:iugYisN38csVNIZamZ84mzXaPTABxU+I2yZ+CzL/ddQ=,tag:wNGJcoYN2obnoKY7uchYiw==,type:str]
|
|
|
|
|
DISCORD_TOKEN: ENC[AES256_GCM,data:hdrjzSqwKmUdmdLl8dOMUPzLxfZf3H4Z6D9b+PIn/nzapQAPECihrxHZswayinYV3nbcZKj2Qh3Aw2jzaP0OpYM6HFdZmosA,iv:nE4utRtwNCDEWOKjTaobpXJHWkXY6LQE1EvHGH+tUH0=,tag:+3UC7N8B1WCCPzBzmB4yog==,type:str]
|
|
|
|
|
CENTRALIS_TOKENS: ENC[AES256_GCM,data:nlDM6Y4rUuAiITo1iN/khDFiwCH8UlVA42SaB1d1a4CG7uVMZnl369MVTMWEXhe4GFOtXlSYgHt7XUMkVmCGQzfBwXed6VZcMPMD9XVkbdYz8+FtrOsf0KVQWvNOHQ6MnvOGMb/CVFBeo0A=,iv:OAw7hXOgAlUQWViCb/fkfqXaNEcyu7947ttbaqHYceM=,tag:sUoVL7Fac9c4dil/+bz7fw==,type:str]
|
secrets: configure Centralis Google sign-in for prod
Centralis has shipped the OAuth 2.1 authorization server since b194603, but
prod ran with none of it configured, so the connector could only offer a
bearer token. buildOAuth() needs a Google client AND a team list; this adds
both, plus the Workspace domain.
CENTRALIS_TEAM is an allowlist of addresses, not a domain or group rule --
a rule keyed on the domain grants production reads to anyone who can get an
address in it, and the group equivalent moves that authority to whoever
administers the group. Four addresses, listed:
emi.g owner jin.j owner
klaudia.j member violet.g member
Roles are real gates. owner is everything, including run_on_host, secrets_*,
promote and SQL writes; member is the estate's reads plus the writes that
become PRs. Identity is re-resolved from this value on every request rather
than trusted from the token, so removing a line and restarting revokes
someone at once.
The audit subjects these derive to -- emi.g, jin.j -- deliberately differ
from the CENTRALIS_TOKENS subjects emi and jin. The token registry is for
machines now, so a distinct subject is what makes an audit line answer
whether a person or a cron job did something.
CENTRALIS_GOOGLE_HOSTED_DOMAIN is set because every address is in the
Workspace. It is checked server-side as well as hinted to Google, so it
narrows who can reach the allowlist; it never populates it.
Verified before commit: the vault renders 13 keys that survive
`set -a; . <file>` byte-for-byte, and the rendered CENTRALIS_TEAM parses to
exactly the four members and capabilities above.
2026-08-01 22:42:20 +00:00
|
|
|
CENTRALIS_GOOGLE_CLIENT_ID: ENC[AES256_GCM,data:eTaMLUn/5KyQ8SXpLSZ7VwdoAakRtB9r0ZXcVKjfWywm7KrWee9W7jNu7yPb2MUbitrIQTl/t5qRtru1n9rygpDXXOFvtxSW,iv:ep3BEkwB/izgkHugGow0JfOPvdkPYtotd+/iayFCoxQ=,tag:odbGzuczZbMSU0KJk8jMdw==,type:str]
|
|
|
|
|
CENTRALIS_GOOGLE_CLIENT_SECRET: ENC[AES256_GCM,data:WEOJJD1dR+ygv2OUdaTue1tqVhHWRY/NJaUKNuaG/CHIifk=,iv:39gL9wUnNGf6rirIE0PJj9Uf7p7TWfLbXHiyeYPqfr4=,tag:B0g0GzhE6KNCfF4okanvlg==,type:str]
|
|
|
|
|
CENTRALIS_GOOGLE_HOSTED_DOMAIN: ENC[AES256_GCM,data:WmvQFhCvtgealw==,iv:KMjjdJ1H4hrTWnxvRe16+2Jq35tzQI8N1GsuG4kFY7w=,tag:Afwrmv1btCxK3vOWsnm6iQ==,type:str]
|
|
|
|
|
CENTRALIS_TEAM: ENC[AES256_GCM,data:0lj+Bv9m/cOaEpxNrFDeEmgLNRAaPlfQYDJ7o2wy80lv82iQrOjha9ZBvOC4f65WwzBKlOhcwum7CNRuPlHJ23AE8BXvaYxqudh74MUK7wYH34Yi9o9BENifngKM9h/vmDPlMA8kCgibp6URjRqRGK0rRhSKUA==,iv:9BRBrNZ6Uua+EquhUTQBMJWfPUNsraMNxKWB2MgaYdM=,tag:ePbUmmgOLpptHLKqF9HwzQ==,type:str]
|
secrets: vault dev and Centralis; render dev without common.yaml
Brings the last two credential stores under SOPS, so all three environments and
the control plane are managed the same way.
dev.yaml — dev was not "intentionally not wired in", it was broken
The vault README claimed dev had no real secrets. Both halves were false.
Dev needed secrets it did not have: thermograph-dev-daemon-1 has been in a crash
loop, restarting every ~60s with "neither THERMOGRAPH_INTERNAL_TOKEN nor
THERMOGRAPH_AUTH_SECRET is set; refusing to start" — so dev has had no Discord
gateway and no job timers. With THERMOGRAPH_BASE_URL unset the app also falls
back to https://thermograph.org, so dev's IndexNow pings and verification links
claimed to be prod. dev.yaml gives it its own generated AUTH_SECRET and a real
base URL, and 12 values total.
And dev already held production credentials: backend-deploy-dev.yml injects
S3_ACCESS_KEY/S3_SECRET_KEY into every dev deploy, and the only provisioned
keypair for that bucket is read-write — on the bucket holding prod's backups.
Dev does not need them; without bucket creds the lake service 503s and history
falls through to the archive. Those workflow lines still need removing.
dev renders dev.yaml ALONE, via THERMOGRAPH_SECRETS_SKIP_COMMON=1. Eleven of
common.yaml's sixteen values are live production credentials, the render is a
plaintext concatenation consumed through env_file:, and dev is the operator's
desktop AND the Forgejo runner executing unreviewed dev-branch code with the
docker socket mounted. An override in dev.yaml would not help — last-wins
governs consumers, but prod's value is still physically a line in the file.
Verified: current renderer leaks 28 lines onto dev including both S3 keypairs
and the VAPID private key; patched gives exactly 12 keys and no prod credential.
Beta's render is byte-identical either way.
centralis.prod.yaml — its own file, its own renderer
/etc/centralis.env was hand-edited, which is how a JSON registry got written
unquoted into a shell-sourced file tonight and silently collapsed three
identities to one. The renderer now owns the file.
It is service- AND environment-scoped, not folded into prod.yaml, because
/etc/thermograph.env is loaded into every container in the app stack. Folding
these in would put CENTRALIS_AUTH_TOKEN and CENTRALIS_TOKENS — which
authenticate an endpoint carrying run_on_host and sql_query(write) — into the
web backend's environment, turning a read-anything bug in the app into a
foothold on the control plane.
Quoting is guaranteed three ways rather than assumed. Critically, `sops -d
--output-type dotenv` emits values verbatim, so reusing the existing render path
would have reproduced tonight's bug exactly. The new function decrypts to JSON
and emits POSIX single-quoted assignments; it then sources its own output in a
clean shell and compares every value before touching /etc; and it refuses to
write unless CENTRALIS_TOKENS parses as a non-empty subject->token object after
sourcing. Tested against 16 hostile values including embedded quotes, newlines
and ;rm -rf /.
Value-identity proven, not asserted: rendered vs live compared as *effective*
values on prod (a textual diff would report a false difference, and would report
a false match if the vault had captured quote characters as part of the value),
plus both env files producing a byte-identical `docker compose config` digest.
9 keys, both token subjects preserved. Nothing deployed.
Note for later: /etc/thermograph.env is also shell-sourced, and survives on raw
dotenv only because none of its 32 current values contains a shell-special
character. It is one quoted secret away from the same bug.
Claude-Session: https://claude.ai/code/session_0182KTMrsTHJc3TcewCatJFY
2026-07-25 01:10:51 +00:00
|
|
|
sops:
|
|
|
|
|
age:
|
|
|
|
|
- enc: |
|
|
|
|
|
-----BEGIN AGE ENCRYPTED FILE-----
|
|
|
|
|
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBGcitwT3BoSE9LWE5zejlh
|
|
|
|
|
WlZPYnJUWTlycC9nZnJaK2d3dmFLQWhsS1M4Ckx0c0hPaXVnaUZra3dFdFVJbm93
|
|
|
|
|
N29XNXZtVUN6d3FjNFB5UDNseXNwMDgKLS0tIGZ4ckI1ejEyc2w5alJNSXF3YklW
|
|
|
|
|
cWZrUWdGd3BEdTYvZU5lV1BDcEE4Z0UK2Q/UGFJwBxLeSib1vJhfGAsR+RMLq144
|
|
|
|
|
JEUSbfXvUHvuMyY94DhbXmh2WgqxWYQuvF9UrDLeDw14tNPIGoIpFg==
|
|
|
|
|
-----END AGE ENCRYPTED FILE-----
|
|
|
|
|
recipient: age1xx4dzs0dxlwvkv9sjuqzsphl7lfrxannkfken374yu2qvvcte9sqzktqt2
|
secrets: configure Centralis Google sign-in for prod
Centralis has shipped the OAuth 2.1 authorization server since b194603, but
prod ran with none of it configured, so the connector could only offer a
bearer token. buildOAuth() needs a Google client AND a team list; this adds
both, plus the Workspace domain.
CENTRALIS_TEAM is an allowlist of addresses, not a domain or group rule --
a rule keyed on the domain grants production reads to anyone who can get an
address in it, and the group equivalent moves that authority to whoever
administers the group. Four addresses, listed:
emi.g owner jin.j owner
klaudia.j member violet.g member
Roles are real gates. owner is everything, including run_on_host, secrets_*,
promote and SQL writes; member is the estate's reads plus the writes that
become PRs. Identity is re-resolved from this value on every request rather
than trusted from the token, so removing a line and restarting revokes
someone at once.
The audit subjects these derive to -- emi.g, jin.j -- deliberately differ
from the CENTRALIS_TOKENS subjects emi and jin. The token registry is for
machines now, so a distinct subject is what makes an audit line answer
whether a person or a cron job did something.
CENTRALIS_GOOGLE_HOSTED_DOMAIN is set because every address is in the
Workspace. It is checked server-side as well as hinted to Google, so it
narrows who can reach the allowlist; it never populates it.
Verified before commit: the vault renders 13 keys that survive
`set -a; . <file>` byte-for-byte, and the rendered CENTRALIS_TEAM parses to
exactly the four members and capabilities above.
2026-08-01 22:42:20 +00:00
|
|
|
lastmodified: "2026-08-01T22:40:50Z"
|
|
|
|
|
mac: ENC[AES256_GCM,data:0ru6lJTTjI5aqGsPYrT3ku2jX0sL32W57LBzfmauf/Td32RXqSNE7cdNlLNwoWsdi/moiKzMexKFkWRBbDzTQprGcBOSbjg51g2n7czHEFnkehH1ixfxaunkVRO9chsude+IEndS9o8x5H+/HZA7NVFFEf2Era0DSeY9IIi0i/U=,iv:mmtmQp5DBAt2aahW5bIhKVY59AYeu60hVfrT7Dfe61c=,tag:FkvAiGbbrWdUTa5fJ8v59A==,type:str]
|
secrets: vault dev and Centralis; render dev without common.yaml
Brings the last two credential stores under SOPS, so all three environments and
the control plane are managed the same way.
dev.yaml — dev was not "intentionally not wired in", it was broken
The vault README claimed dev had no real secrets. Both halves were false.
Dev needed secrets it did not have: thermograph-dev-daemon-1 has been in a crash
loop, restarting every ~60s with "neither THERMOGRAPH_INTERNAL_TOKEN nor
THERMOGRAPH_AUTH_SECRET is set; refusing to start" — so dev has had no Discord
gateway and no job timers. With THERMOGRAPH_BASE_URL unset the app also falls
back to https://thermograph.org, so dev's IndexNow pings and verification links
claimed to be prod. dev.yaml gives it its own generated AUTH_SECRET and a real
base URL, and 12 values total.
And dev already held production credentials: backend-deploy-dev.yml injects
S3_ACCESS_KEY/S3_SECRET_KEY into every dev deploy, and the only provisioned
keypair for that bucket is read-write — on the bucket holding prod's backups.
Dev does not need them; without bucket creds the lake service 503s and history
falls through to the archive. Those workflow lines still need removing.
dev renders dev.yaml ALONE, via THERMOGRAPH_SECRETS_SKIP_COMMON=1. Eleven of
common.yaml's sixteen values are live production credentials, the render is a
plaintext concatenation consumed through env_file:, and dev is the operator's
desktop AND the Forgejo runner executing unreviewed dev-branch code with the
docker socket mounted. An override in dev.yaml would not help — last-wins
governs consumers, but prod's value is still physically a line in the file.
Verified: current renderer leaks 28 lines onto dev including both S3 keypairs
and the VAPID private key; patched gives exactly 12 keys and no prod credential.
Beta's render is byte-identical either way.
centralis.prod.yaml — its own file, its own renderer
/etc/centralis.env was hand-edited, which is how a JSON registry got written
unquoted into a shell-sourced file tonight and silently collapsed three
identities to one. The renderer now owns the file.
It is service- AND environment-scoped, not folded into prod.yaml, because
/etc/thermograph.env is loaded into every container in the app stack. Folding
these in would put CENTRALIS_AUTH_TOKEN and CENTRALIS_TOKENS — which
authenticate an endpoint carrying run_on_host and sql_query(write) — into the
web backend's environment, turning a read-anything bug in the app into a
foothold on the control plane.
Quoting is guaranteed three ways rather than assumed. Critically, `sops -d
--output-type dotenv` emits values verbatim, so reusing the existing render path
would have reproduced tonight's bug exactly. The new function decrypts to JSON
and emits POSIX single-quoted assignments; it then sources its own output in a
clean shell and compares every value before touching /etc; and it refuses to
write unless CENTRALIS_TOKENS parses as a non-empty subject->token object after
sourcing. Tested against 16 hostile values including embedded quotes, newlines
and ;rm -rf /.
Value-identity proven, not asserted: rendered vs live compared as *effective*
values on prod (a textual diff would report a false difference, and would report
a false match if the vault had captured quote characters as part of the value),
plus both env files producing a byte-identical `docker compose config` digest.
9 keys, both token subjects preserved. Nothing deployed.
Note for later: /etc/thermograph.env is also shell-sourced, and survives on raw
dotenv only because none of its 32 current values contains a shell-special
character. It is one quoted secret away from the same bug.
Claude-Session: https://claude.ai/code/session_0182KTMrsTHJc3TcewCatJFY
2026-07-25 01:10:51 +00:00
|
|
|
unencrypted_suffix: _unencrypted
|
|
|
|
|
version: 3.13.2
|