1.7: the composer exists and the composition does not
Correcting a tick and a claim I made one commit ago. 4.1 does not wait on an enrolment user per live token; it waits on the whole composition, of which that user is one input. Tasks 1.3 and 1.4 are honest about what they built — the composer, the derivation, the permission model, the stream and consumer definitions, the asserter, all pure and held by unit tests and a golden composition. Nobody wrote the caller. Measured: outside the package that defines them there is not one use of the composer, the permission derivation, the stream set, the stream asserter or the principal type. Step 1's "done when" claims every account and permission composed from the manifests, and a mesh raised today would stand up a server with no user list at all. It also needs state the mesh does not keep. Design 25 §4 says the file holds bcrypt hashes and that passwords are minted and sealed exactly as today — but today the mesh mints one, hands it to the broker through a management call, seals the plaintext to the holder and keeps nothing. With no management call the hash has to survive every later recomposition, because the first thing a new module or a person's access change touches is a file that must still hold every other user's password. No bcrypt hash is stored anywhere in the controller. Named as its own task rather than folded into 1.3, so the gap between "the parts of step 1 exist" and "the mesh does any of it" is visible.
This commit is contained in:
@@ -150,6 +150,29 @@ paper is wrong until there is a second mesh to find out.
|
||||
and names no broker module anywhere in its source. What remains is naming `nats` instead of
|
||||
the deprecated broker where a genesis module set is declared, which is scenario and installer
|
||||
configuration — carried with 1.6 rather than before it.
|
||||
- [ ] 1.7 **the composition, delivered** — the controller gathering its principals, composing the
|
||||
file, and asserting the streams and consumers on start.
|
||||
|
||||
> **This corrects a tick, not a decision.** Tasks 1.3 and 1.4 are ticked and they are honest
|
||||
> about what they built — the composer, the derivation, the permission model, the stream and
|
||||
> consumer definitions, the asserter, all pure and held by unit tests and a golden
|
||||
> composition. What nobody wrote is the *caller*. Measured on the feature branch: outside the
|
||||
> package that defines them, there is **not one** use of the composer, the permission
|
||||
> derivation, the stream set, the stream asserter or the principal type. Step 1's "done when"
|
||||
> claims "every account and permission composed from the manifests", and a mesh raised today
|
||||
> would stand up a server with no user list at all.
|
||||
>
|
||||
> It also needs state the mesh does not keep. Design 25 §4 says the file holds bcrypt
|
||||
> hashes, and passwords are "minted and sealed exactly as today" — but today the mesh mints a
|
||||
> password, hands it to the broker through a management call, seals the plaintext to the
|
||||
> holder and **keeps nothing**. There is no management call here, so the hash has to survive
|
||||
> for every later recomposition: the first thing a person's access change or a new module
|
||||
> touches is a file that must still contain every other user's password. No bcrypt hash is
|
||||
> stored anywhere in the controller today.
|
||||
>
|
||||
> Named as its own task rather than folded into 1.3 so the gap is visible: the parts of
|
||||
> step 1 exist and the mesh does not yet do any of it.
|
||||
|
||||
- [ ] 1.6 the genesis-broker bed — **deferred**: beds are run once, at the end, rather than per
|
||||
step (novox/hq design 22's rule, and the operator's instruction). Every claim step 1 makes
|
||||
is covered by a unit test or was demonstrated against the real server; what the bed adds is
|
||||
@@ -324,11 +347,8 @@ pays for itself furthest away.
|
||||
the subject-alternative-name constraint recorded under 3.6 is that client's, because it takes
|
||||
PEM strings with no verify hook. A host checks the fingerprint and nothing else.
|
||||
|
||||
Still outstanding: **something that composes an enrolment user per live token.** Nothing does,
|
||||
on either bus — on the old one the account is made imperatively through the broker's
|
||||
management API when a token is issued, and here there is no management API, so issuing a token
|
||||
has to recompose the server's configuration. That is the last piece of enrolment on the new
|
||||
bus, and it is the only thing between the two links and a mesh raised on NATS from nothing.
|
||||
Nothing here composes an enrolment user per live token, and that is **1.7's**, not this
|
||||
task's: it is one input to a composition that does not happen at all yet.
|
||||
- [x] 3.6 the tool runtime's client on NATS, behind the unchanged sdk contract — round-tripped
|
||||
against a real server: a tool answered across two connections, a throwing handler reaching
|
||||
the caller as an error rather than a timeout, an event delivered once with its key, body,
|
||||
@@ -414,9 +434,9 @@ it, and the beds that need a mesh living on NATS can finally run.
|
||||
held by a `nak`-with-delay cycle still reaches the enrolling node, proving the reply travels
|
||||
in the payload and not the transport field the consumer's ack has claimed. The server-enforced
|
||||
permissions were proved at step 1 and are not re-proved here
|
||||
— **waiting on one thing only**: an enrolment user composed per live token (3.5). Both links
|
||||
speak NATS and every claim above has a unit test or a check against a running server behind
|
||||
it; what no test can stand in for is a mesh raising itself, which is what this bed is
|
||||
— **waiting on 1.7, the composition.** Both links speak NATS and every claim above has a unit
|
||||
test or a check against a running server behind it; what none of them needs is a bus that
|
||||
composed its own accounts, because each supplies its own. A mesh raising itself does need one
|
||||
- [ ] 4.2 a build source's change reaches the builder over the bus, and the build that follows is
|
||||
the one the change asked for — **blocked by
|
||||
[issue 127](../../04-ISSUES/127-a-module-event-derives-a-subject-nothing-publishes/00-report.md)**
|
||||
|
||||
Reference in New Issue
Block a user