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

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
+ <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.