jschoubben
49b1136ded
164 a credential that must be accepted is minted anyway 165 one accepted value must be accepted once per consumer 166 a requirement cannot be optional 167 code several modules share has no home 168 a setting reaches every file and every contribution
1.4 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| open | 2026-09-30 |
|
164 — A credential that must be accepted is minted anyway
What was observed
Provisioning ace's modules. Several providers hold exactly one credential they did not get from the
mesh and cannot take one from it: a Servarr app's API key (sonarr, radarr, lidarr), jackett's API key,
plex's X-Plex-Token, nzbget's ControlPassword, qBittorrent's WebUI password. Their consumers' pair
credential must be accepted by the operator (ADR 0092). Until it is, SecretFor mints a random
value, seals it to both ends, and reports nothing: the value can never work.
Every consumer therefore had to learn to detect it — try the credential against the provider first,
refuse a value the provider rejects, print the secret accept command — six write-in steps, one probe
each (ombi, home-assistant, and the four download-stack consumers). qBittorrent bans an address after
five failed logins, so a consumer retrying a minted value locks itself out.
What would be right
A provision (or a provider's serves) can declare its pair credential accepted-only. The plan then
refuses the pair — naming the accept command — instead of minting, and a consumer is never handed a
value the mesh knows cannot work.