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
1023 B
1023 B
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| open | 2026-09-30 |
|
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.