Issues 237, 238: a self-contradicting assign answer, and the operator's address banned

2026-10-04 17:06:38 +02:00
parent 4a8a378ef9
commit 2580fb6839
2 changed files with 80 additions and 0 deletions
@@ -0,0 +1,40 @@
+---
+status: open
+opened: 2026-10-04
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 237 — `assign` says a seat is held and that the node does not resolve for lack of it, in one answer
+
+## What was observed
+
+2026-10-04. A workstation already ran a module that contributes to `node-hotkeys`, and the module
+holding that seat was assigned to it. The answer said, in order:
+
+```
+<node> is assigned triggerhappy
+  and asus-zephyrus-g14 on <node> now has node-hotkeys held
+  run `push <node>` to send it
+<node> is left out of the rest of the mesh: it does not resolve: these assignments cannot be applied:
+  - asus-zephyrus-g14 on <node> depends on node-hotkeys, which nothing on <node> holds (novox/hq ADR 0207) — assign one that holds it: triggerhappy
+```
+
+Both statements cannot be true. `plan` for the node, run straight after, resolved: it held
+`node-hotkeys`. A push applied all 300 resources.
+
+## Why it matters beyond this instance
+
+The last lines of an answer are the ones a person and an agent act on. Here they say the node is cut
+off from the mesh and name the remedy as the assignment just made. A person would assign it again,
+or stop the rollout. An agent following the instruction loops. The tail of `assign` comes from a
+second view of the mesh, and that view was not the one the assignment had just changed.
+
+## Open questions
+
+1. Where does the "left out of the rest of the mesh" judgement read the node's assignments from, and
+   why did it miss the one just recorded: a cached resolution, a read before the write committed, or
+   the catalogue as registered before the contributing module's new version?
+2. Should an answer that contradicts itself be impossible by construction, with every line of it
+   derived from one resolution taken after the write?
@@ -0,0 +1,40 @@
+---
+status: open
+opened: 2026-10-04
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 238 — The mesh banned its own operator's address for four weeks
+
+## What was observed
+
+2026-10-04. An agent working for the operator on a workstation polled the forge's ssh port in a loop,
+about forty connections in ten minutes, waiting for a branch. The intrusion-prevention holder on the
+control node banned the operator's home uplink address in the forge's jail for a day, and then in
+`recidive` for four weeks.
+
+From then on, nothing in the operator's home could reach the control node on the banned ports: not
+the workstations, not the laptop. The `unban` verb of `node-intrusion-prevention` lifted it, once the
+address was found in a ban list of over 400 entries.
+
+## Why it matters beyond this instance
+
+[ADR 0186](../../02-DECISIONS/0186-a-ban-list-never-holds-a-neighbour.md) says a ban list never holds a
+neighbour. The operator's home address is the one address the mesh can be sure belongs to it. Every
+machine behind it is a node, and the operator reaches the mesh from it. Yet nothing told the jails
+so. A ban there locks the mesh out of itself, for longer than any repair takes, and the remedy needs
+a path that does not go through the banned address.
+
+The output channel being researched
+([research 028](../../01-RESEARCH/028-the-meshs-output-channel/00-overview.md)) would not have said
+anything either: a ban is not reported as an event.
+
+## Open questions
+
+1. Which addresses are the mesh's own? The public uplink of every node, as each node reports it, and
+   the operator's known addresses. Should every jail's ignore list carry them, derived rather than
+   configured?
+2. Should a ban of an address any node reports as its own be refused, or at least emitted as an event
+   the output channel carries?