From ee70d5b4516e29b559c9c46643f3cb9c59c563c0 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 14 Sep 2026 21:01:32 +0200 Subject: [PATCH] =?UTF-8?q?Issue=20048=20=E2=80=94=20a=20stated=20rule=20a?= =?UTF-8?q?bout=20the=20registry=20is=20enforced=20by=20nothing?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .../00-report.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 04-ISSUES/048-nothing-makes-a-machine-trust-the-mesh-registry/00-report.md diff --git a/04-ISSUES/048-nothing-makes-a-machine-trust-the-mesh-registry/00-report.md b/04-ISSUES/048-nothing-makes-a-machine-trust-the-mesh-registry/00-report.md new file mode 100644 index 0000000..ebc9cf2 --- /dev/null +++ b/04-ISSUES/048-nothing-makes-a-machine-trust-the-mesh-registry/00-report.md @@ -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 + + ::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.