Bus node: follow the grants part's sealed user list after the operator's take-over, never both sources; hand the vault the loaded hashes (issue 1945) #145

Merged

mesh-tools merged 7 commits from feat/1945-user-list-switch into main 2026-10-26 12:21:55 +00:00

Conversation 4 Commits 7 Files Changed 10

+910 -25

7 Commits

Author	SHA1	Message	Date
jschoubben	e88ddab241	An apply of the bus module waits when the list on the machine cannot be read while the grants part's is followed, so the file is never removed as an orphan (review of the switch, issue 1945)	2026-10-26 12:54:06 +01:00
jschoubben	06f70e11ee	Bring in the adoption handing; the bus node writes nothing before it heard the switch, retries the key's watch and keeps the follow last heard, and an apply never writes the controller's list while the grants part's is followed (review of the switch, issue 1945) ... Merges fix/1945-adopt-hashes 1a190090. A new follower (one per link) waits for the grants part's key to catch up before its first write, so a restart after take-over never writes the controller's list first. A refused or ended watch is tried again on link.Backoff, the have says why it is not watched, and the key last heard, kept beside the node's state, holds meanwhile. While the grants part's list is followed, the bus module's composition is applied with the list on the machine in place of the controller's. The grants list is never handed to the vault. Pins mesh-sdk c2a410bb.	2026-10-26 12:30:07 +01:00
jschoubben	61cec66ba8	gofmt the follower's test (issue 1945)	2026-10-26 12:08:37 +01:00
jschoubben	5e2fadce15	Pin mesh-sdk at the group's head 83ee7769 (issue 1945)	2026-10-26 12:07:10 +01:00
jschoubben	882e75c954	The bus node follows the grants part's sealed user list from take-over, the controller's otherwise, never both (ADR 0547 clauses 7, 8; issue 1945) ... On the node whose compositions carry the bus's list, the engine also watches mesh-grants' key user-list.sealed. While it says follow grants, the object it names is read by name, opened with this machine's sealing key, checked against the key's digest and the guard, and written to the same file at 0600 only when its digest differs; the bus reloads it itself. The have says which list is followed and this machine's sealing key, which the grants part seals to. The follower's test waits for its watch to catch up before a later put, which raced under load. Pins mesh-sdk 175a5567.	2026-10-26 12:06:17 +01:00
jschoubben	1a190090ab	The engine states its key again until it hears the vault's key, and at a slow interval after, so a vault delivered after it or a changed vault key is heard (review of the adoption handing, ADR 0547 clause 9)	2026-10-26 12:03:12 +01:00
jschoubben	fd381567f4	The bus node hands the loaded list's hashes to the vault, sealed to its key, in the bus module's have (ADR 0547 clause 9, issue 1945) ... The vault holds no value for the controller's own account, the node accounts and the enrolled devices, so it cannot hash them, and take-over waits on their hashes. The bus node's engine is the one part that has them, in the list the bus loaded. Its follower of the user list now puts every loaded user's bcrypt hash in the bus module's have, sealed to the vault's own key (mesh-sdk delivery.AccountsHanded), so of every reader of the have bucket the vault alone opens it; the clear part says only the list's digest, the key's fingerprint and how many users. The vault's key is heard from its answer to node-key, which the engine already asks at start; a first or changed key looks at the list again. It is sealed again only when the list on the machine or the vault's key changes; a refused list hands the list kept on the machine. The vault takes from it only the users it holds no value for. Also: the user list follower's test sent its later puts before the watch had handed the keys there before it, so two of its cases failed on main whenever the goroutine started late; the feed now says when the watch began.	2026-10-26 11:32:36 +01:00