Issue 069: the count is the catalogue's, not the report's

2026-09-21 17:51:40 +02:00
parent 62ff9a5bd3
commit 159a583cf0
1 changed files with 8 additions and 6 deletions
@@ -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