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
25 lines
1023 B
Markdown
25 lines
1023 B
Markdown
---
|
|
status: open
|
|
opened: 2026-09-30
|
|
located-in:
|
|
- mesh-controller internal/inventory/secrets.go (AcceptSecretForPair is per consumer)
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 165 — One accepted value must be accepted once per consumer
|
|
|
|
## What was observed
|
|
|
|
On ace, jackett's API key is the pair credential for sonarr, radarr, lidarr and bookshelf; sonarr's is
|
|
the credential for ombi, bazarr and home-assistant. It is **one value**, owned by the provider — yet
|
|
`secret accept` is per pair, so ace's download stack alone needs 12 accepts of 3 values, and rotating
|
|
a provider's key means finding and re-accepting every pair. Missing one leaves that consumer on a
|
|
stale (or minted, 164) value.
|
|
|
|
## What would be right
|
|
|
|
A provider-level accept: "this provider's credential for `<provision>` is X" — delivered to every
|
|
consumer pair, current and future, and rotated in one place. Pairs whose credential is genuinely per
|
|
consumer (postgres, keycloak, mosquitto, influxdb — minted and created by a provisioner) are unaffected.
|