jschoubben
ee70d5b451
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
4.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-14 |
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, 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.