From cc3af29084673455182dc98765b6c8eb857b4b3b Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 22 Sep 2026 22:43:17 +0200 Subject: [PATCH] Issue 092: genesis publishes to a registry the container runtime does not yet trust --- .../00-report.md | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 04-ISSUES/092-genesis-publishes-to-a-registry-the-runtime-does-not-trust/00-report.md diff --git a/04-ISSUES/092-genesis-publishes-to-a-registry-the-runtime-does-not-trust/00-report.md b/04-ISSUES/092-genesis-publishes-to-a-registry-the-runtime-does-not-trust/00-report.md new file mode 100644 index 0000000..a9ccf49 --- /dev/null +++ b/04-ISSUES/092-genesis-publishes-to-a-registry-the-runtime-does-not-trust/00-report.md @@ -0,0 +1,59 @@ +--- +status: open +opened: 2026-09-22 +located-in: [] +fixed-by: +amended-design: +--- + +# 092 — Genesis publishes to a registry the container runtime does not yet trust + +## What was observed + +On the first real genesis, on a machine in use, 2026-09-22. + +Genesis raises the mesh's registry, then pushes the control plane's image into it so that the +control plane can be reinstalled as an ordinary module pinned to a digest. The push failed: + +``` +the container runtime would not push
/mesh-controller:genesis: +Get "https://
/v2/": http: server gave HTTP response to HTTPS client +``` + +The mesh's registry speaks plain HTTP, deliberately: every path to it is inside the private +network's encryption ([ADR 0082](../../02-DECISIONS/0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md)). +The container runtime refuses plain HTTP to a registry it has not been told to trust, and **the +thing that tells it is the networking module**, which genesis installs at step 16 — six steps +after the push. + +So genesis cannot complete on a machine whose runtime was not already told, out of band, to trust +the address the mesh is about to serve its own images from. + +The lab never sees it: its base image writes that trust into the runtime's configuration before +any bed starts. That is the same blind spot [issue 084](../084-taking-networking-on-an-adopted-node-restarts-every-container/00-report.md) +names from the other side. + +Worked around by hand on the machine: the mesh's registry added to the runtime's trusted list, +keeping every key already there, and the runtime **reloaded** rather than restarted, so nothing it +was running stopped ([ADR 0102](../../02-DECISIONS/0102-the-mesh-writes-into-a-shared-file-never-over-it.md)). +Genesis then continued. + +## Why it matters beyond this instance + +Genesis is meant to take a machine from nothing to a mesh without anyone editing files on it. It +has one step that cannot work unless somebody already did. Every future first node meets this, not +only a node adopted beside a predecessor, and the order is what makes it so: the trust the push +needs is installed after the push. + +It also breaks the rule that each step says what it needs before it changes anything. Preflight +checks that the bundle's registries are reachable. It does not check that the runtime will speak +to the one the mesh is about to raise. + +## Open questions + +- Should genesis write the runtime's trust itself, before the publish step, the way it writes + everything else the foundation needs — and hand it to the networking module afterwards? +- Or should the push not need it: a registry served over TLS from the start, or an image loaded + rather than pushed? +- Should preflight refuse a genesis whose runtime does not trust the registry it is being given, + rather than letting it fail at step 10?