A password, token or API key is the vault's, never a setting (hq issue 342) #264

Merged

mesh-admin merged 2 commits from fix/342-a-secret-is-never-a-setting into main 2026-10-13 05:52:05 +00:00

Conversation 6 Commits 2 Files Changed 25

+783 -19

2 Commits

Author	SHA1	Message	Date
jochen	eb42806379	Make grafana prefer the vault's password, and let the secrets list only shrink (hq issue 342) ... grafana's client logged in with a token setting ahead of the vault's admin password, and its runtime config let a layer set token. The token setting is now ignored and said, token is protected, and the vault's password comes first. checks/secrets/known could gain a line hiding a newly unprotected key. merge-check.sh now judges it against the trunk's copy at the merge base, and refuses an added line.	2026-10-13 07:43:08 +02:00
jochen	fe2040c65e	Keep every password, token and API key the vault's, never a setting (hq issue 342) ... A setting outranked the vault: baserow, grafana, letta and unifi merged a layer's password over the ${secret:...} in their runtime config, and the gitea, home-assistant, icecast, influxdb, mailu and nextcloud clients read the settings file before the vault's file. A secret in a setting cannot be rotated and is read back by the settings verb. The four files now keep their password protected, so the controller refuses a setting of it. The six clients ignore a secret in the settings file and say so once, by key and never with the value; icecast reads its admin password from the vault's file. checks/secrets refuses a mergeable file whose secret a layer could replace; searxng's nested server.secret_key is listed as known until the controller protects a nested key.	2026-10-13 07:32:19 +02:00