A grant file and a provisioned login name the module too

novox/hq 04-ISSUES/022: a consumer is a module on a machine, not a
machine. The mesh now writes <node>.<module>.secret and the provisioners
name the role and the access key after both.

The fixtures here write what the mesh writes, so they move with it —
that is the whole point of them, and a fixture that kept the old shape
would agree with the bug rather than catch it.

The object-store assertions are the ones that mattered most: one store
holds every bucket behind one endpoint, so isolation is a policy rather
than a property. One access key per machine meant every module on a node
shared it, and the policy confining each consumer to its own bucket
confined none of them.
This commit is contained in:
2026-09-01 02:45:40 +02:00
parent 0ffb24ff5d
commit e7f4a49e40
3 changed files with 27 additions and 27 deletions
+1 -1
View File
@@ -22,7 +22,7 @@ and is then given, by the host, from an ordinary declaration:
| | |
|---|---|
| `mesh.json` | every consumer, what it asked for, and where its credential is |
| `<node>.secret` | one consumer's password, alone in the file, sealed in transit and written in plain by the host |
| `<node>.<module>.secret` | one consumer's password, alone in the file, sealed in transit and written in plain by the host. Named after both, because a consumer is a module on a machine and a node routinely runs several (`novox/hq` 04-ISSUES/022) |
Two files rather than one because the mesh discarded the plaintext and cannot compose a document
containing it. The consequence is a good one: the readable half stays readable, and the secret