From 159a583cf0d3b23eec46f1172b5eeaa46d16241f Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 21 Sep 2026 17:51:40 +0200 Subject: [PATCH] Issue 069: the count is the catalogue's, not the report's --- .../01-diagnosis.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md b/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md index b6511d7..b82ce93 100644 --- a/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md +++ b/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md @@ -4,12 +4,14 @@ a pair credential is keyed on (name, consumer node, consumer module, provider), and the login the vault derives is keyed on the (node, module) pair. Two secrets for one module and one vault collide on every key. -2. The third question was answered by reading the ten modules. Six of the "two" cases hold two - names for one value or a value derived from another (an admin password and a token only ever - set from it, a relay user that is a fixed string beside the relay password). Those are one - secret each, and the module's own business to derive from. The "three or more" cases are - genuinely independent: a root certificate, its key and that key's password are three values - with three lifetimes. +2. The third question was answered by reading the catalogue as it is today: nine modules hold two + or more own secrets besides their broker account. Two hold a relay user beside a relay + password — the user is a name, not a secret, and could travel as configuration. The other + seven hold genuinely independent values with independent lifetimes: an internal token beside + an admin password; a source, an admin and a relay password; an admin password beside an API + token; a root certificate, its key, that key's password and an intermediate's. None of those + derives from another. So "one value per module, derivation the module's business" is not an + answer for most of them. 3. So the answer is neither option as the report framed them. A module keeps one `secret` provision per independent value, and needs a way to require the same provision name more than once under distinct local names — the way `secrets:` already maps a provision to a path. That