5 Commits

Include renames

Author	SHA1	Message	Date
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	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	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
jschoubben	5e71ab6ae6	Count the bus's users from the list a digest names, take only a composition of this node and module, and refuse a list that would lock the mesh out (review of the bridge, ADR 0547 §8) ... B1: the controller sends the user list by digest (over 64 KiB), so its users are counted from the list as resolved, not from the composition's inline content, which is empty then. R1: a composition signed for another node or module than its key names is no source. R2: a list without the controller's own user, or one that drops more than half the users of the file on the machine, is not written; the have says why and the file on the machine is kept.	2026-10-25 22:00:05 +01:00
jschoubben	3f02bd7ff6	The bus node writes the bus's user list alone from the newest composition of the bus module, with no want, and says it in the bus module's have (ADR 0547 §8, issue 1945) ... The list reached the bus only through a want of the bus module, which nobody writes (ADR 0539 §15): on 2026-10-25 it stood from 11:23 to 20:50 and was put back by hand. The node agent now follows its composition bucket for the newest signed composition carrying the user list, writes that file alone through the apply's file step when it differs (mode 0600, read back, recorded as the module's), moves nothing that reads it (the bus module's entrypoint reloads the server in place), never goes back to an older list, looks again after every apply of the bus module, and says source, revision, wanted and written digests, users and any error in the bus module's have (mesh-sdk UserListWritten). Read with mesh-delivery-view.node_haves (module nats); the bus's own nats_user_can says in_force once it reloaded.	2026-10-25 21:50:49 +01:00