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
30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-09-30
|
|
located-in:
|
|
- mesh-controller internal/inventory/secrets.go (SecretFor mints a pair credential nobody accepted)
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 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.
|