novox/hq
3
0
Fork 0
Code Issues Pull Requests 5 Releases Wiki Activity

Issue 129: three machines of four trust the mesh, not one

Browse Source 
Extended after the first was proven. Every converged machine now holds
the anchor and verifies an internal name with a plain client; before,
the two unassigned ones answered 'unable to get local issuer
certificate' and held no entry for the mesh.

ace is excluded on purpose: it is adopted, so a module assigned there is
held rather than run, which is right and is not trust.

Both the resolution and 0147's insight said one machine of four, which
was true for about twenty minutes.
This commit is contained in:
jschoubben
2026-09-30 02:30:23 +02:00
parent 5036b927b9
commit d009c3efef
2 changed files with 26 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md
+3 -1
View File
@@ -139,7 +139,9 @@ written this way until the bed runs.
> Run on the live mesh because that is where a change is verified now
> ([ADR 0149](0149-the-live-mesh-is-the-test-bed.md)), and the bed still cannot raise a foundation. The
> evidence is [issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/02-resolution.md).
> It ran on **one** machine; three others still trust nothing of the mesh's.
> Extended the same day to every converged machine — `novox`, `g14` and `shanks` each hold the anchor
> and verify with a plain client. `ace` is excluded on purpose: it is adopted, so a module assigned
> there is held rather than run, which is right and is not trust.
## Consequences
04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/02-resolution.md
+23 -5
View File
@@ -73,11 +73,29 @@ in the module says this; it is the host's removal order that makes the module's
## What this leaves
- **One machine, not four.** `novox`, `g14` and `ace` still trust nothing of the mesh's. The report's
reasoning — that being on the private network is what makes a machine one that speaks to the mesh's
names — argues for all of them, and ADR 0147 is written for a module assigned per machine rather than
a fact carried to every machine on the network. Whether it should instead arrive the way the roster
and the registry trust do is a real question and is not this record's to answer.
- **Three machines of four** *(extended the same day, after the first was proven)*. `ca-trust` is now
assigned to every converged machine, and each verifies with a plain client:
```
novox mesh CA in trust store: 1 https://git.<node>.internal/ -> 200
g14 mesh CA in trust store: 1 https://git.<node>.internal/ -> 200
shanks mesh CA in trust store: 1 https://git.<node>.internal/ -> 200
```
Before, each of the two that had not been assigned it answered
`curl: (60) … unable to get local issuer certificate (20)` and held no entry for the mesh.
**`ace` is deliberately not among them.** It is the adopted machine, still carrying the
predecessor's resolver and filter, and it is not converged until the network and module-assignment
work is settled. Assigning a module to it would hold rather than run
([ADR 0100](../../02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md)), which is
correct and is not the same as trusting anything.
- **It arrives per assignment, which is a shape worth questioning.** The report's reasoning — that
being on the private network is what makes a machine one that speaks to the mesh's names — argues
for a fact carried to every machine on the network, the way the roster and the registry trust are.
ADR 0147 chose a module assigned per machine, and this record does not reopen it; the cost is that
a machine joining the mesh trusts nothing until somebody remembers a second command.
- **`service-manager` reports `degraded` on this machine** and the module ran anyway. Worth knowing that
the capability gate passes on a degraded service manager, since a module whose whole delivery is a
unit is the kind that would be worst served by one.