Issue 048 — a stated rule about the registry is enforced by nothing

The registry says every machine pulls from it and opens its port to the mesh for that reason. A machine that tries is refused by its own container runtime: the registry serves plain HTTP and anything but loopback is treated as HTTPS. It has never failed, and that is the finding. Every proof that a machine can fetch a mesh-built artifact was a proof about the machine that built it, where the reference was loopback. The bed that uses a routable address gets away with it because the harness writes the runtime's configuration before the mesh exists. Kept separate from 042, which they are easy to confuse: that one is about not being allowed to pull, this one about not being able to whatever the credential says. Fixing 042 alone leaves a machine with a valid account for a registry its runtime will not talk to. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
2026-09-14 21:01:32 +02:00
parent 3121e47245
commit ee70d5b451
1 changed files with 80 additions and 0 deletions
@@ -0,0 +1,80 @@
 ---
 status: open
 opened: 2026-09-14
 located-in: []
 fixed-by:
 amended-design:
 ---
 # 048 — Nothing makes a machine trust the mesh's own registry
 ## Symptom
 The registry module says, in its own manifest, that its port is open to the mesh because *every
 machine pulls images and artifacts from here*. A machine that tries to do so is refused by its
 container runtime before the mesh is involved at all: the registry serves plain HTTP, and a
 container runtime treats any registry that is not loopback as HTTPS.
 Nothing in the mesh arranges otherwise. There is no resource that configures a runtime's view of
 the registry, no field in a manifest for it, and no step in joining that establishes it.
 **It has never failed, and the reason it has never failed is the finding.** Every proof that a
 machine can fetch a mesh-built artifact has been a proof about the machine that built it, where the
 reference was loopback and loopback is trusted by default. The one bed that pushes to a routable
 address gets away with it because *the lab* writes the runtime's configuration before the mesh is
 raised, naming the documentation ranges its scenarios use. That file is the lab's, not the mesh's,
 and no machine outside a bed has one.
 Observed while fixing a neighbouring fault: the builder recorded artifacts under a loopback address
 (fixed — the binding states where the provider is, and it now uses it). Correcting the address is
 what makes this reachable, and therefore what makes this visible.
 ## Why this matters
 **A stated rule is enforced by nothing.** The registry declares that the whole mesh pulls from it
 and opens a port to the mesh accordingly. That is the design. Whether any machine can act on it
 depends on a file the mesh does not write, does not read, and has no opinion about.
 **It is the other half of [042](../042-nothing-gives-a-node-an-account-for-a-registry/00-report.md),
 and the two are easy to confuse.** 042 is about a machine not being *allowed* to pull — no
 credential. This is about a machine not being *able* to, regardless of credential, because the
 transport is refused. A fix for 042 alone would leave a machine holding a valid account for a
 registry its runtime will not talk to, which fails with an error about certificates and reads as a
 credential problem.
 **It decides something about the private network that has not been decided.** Serving artifacts
 over plain HTTP is defensible if the private network is the boundary, and indefensible if it is
 not — and either way it is a position, not an omission. Today it is an omission that happens to
 work in one place.
 **It is a joining problem before it is anything else.** The first machine never meets it. Every
 machine after it does, on the first module the mesh built rather than fetched — which is most of
 them.
 ## Evidence
 A machine raised by the installer, asked what its runtime trusts:
 ```
 Insecure Registries:
 127.0.0.0/8
 <the documentation ranges this lab uses>
 ::1/128
 ```
 Everything but the loopback entry was written by the harness. The mesh contributed none of it.
 ## Open questions
 - **Should the mesh's registry serve TLS?** It would make the transport a property of the registry
  rather than of every machine that talks to it, and the mesh already issues certificates. What
  signs it, and what a machine checks it against, are the real questions.
 - **Or should a machine's runtime be configured by the mesh** — a resource that states what this
  machine trusts, applied like any other? That puts a node-wide setting in a module's hands, which
  may be the wrong ownership.
 - **What is the boundary the answer assumes?** If plain HTTP inside the private network is
  acceptable, that assumption should be recorded with what it takes for granted about who is on
  that network — and checked, rather than inherited from a harness.
 - **How does this interact with genesis?** The installer publishes before the mesh can grant or
  configure anything, and gets away with loopback. Whatever is decided has to leave that moment
  workable.