3 Commits

Include renames

Author	SHA1	Message	Date
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
mesh-tools	bff1ac14a1	Feature 57 (config and provisioning): release mesh-host, the reviewed release branch on top of main	2026-10-16 08:24:13 +00:00