jochen
c839d9ac26
Two things the report got wrong, and one it could not have found the way it looked. Disclosure first: it carried a real hostname and an absolute node path, in a public repository. Both are gone; the ingress, the modules and the routes are named by role, as the rest of 04-ISSUES does. The count was low. Basic authentication has three dependents in the catalogue, not one — the key-value store's browser UI, a database web UI, and the ingress's own dashboard. All three are credential-less admin surfaces whose only gate is a middleware the mesh's proxy lacks. The earlier version read only the node's dynamic configuration directory, which cannot see what modules declare as container labels; counting needs both sources, and the report now says so. Two gaps were missing entirely. Redirect rules: two live routes canonicalise a www name onto its apex, they exist only on the node and not in the catalogue, and they fail silently rather than erroring. And path-scoped routing with priority, which is the one that reorders the issue: the table maps host to exactly one target, so a host cannot be routed two ways, and the refusal rule matches a path on a host already routed elsewhere. Authentication and a source filter would not make it expressible. Path scoping is a prerequisite, not a sibling. Also corrected: the refusal rule was described as an address-scoped deny. It is an allow-list holding a single documentation-range address — deny-everyone — so reading it as address-scoped points at the wrong fix. And its severity was understated: its own header records it as incident response closing an abused write primitive, which is not "a real exposure" but a live mitigation. The open questions now say plainly that they are design questions and the fix should not be written before they are answered, and one is added: whether a declaration may carry a credential at all.
7.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| located | 2026-09-25 |
|
116 — The mesh's proxy applies no policy to a request: no authentication, no source restriction, no path scoping, no redirects
What was observed
On 2026-09-25, deciding whether the mesh's own reverse proxy (to-be 08) can replace the ingress the mesh adopted from the predecessor, as the permanent public entry point. The standing requirement is that the mesh does at minimum what the system it replaces already does, so the comparison is against the predecessor's real, live configuration and its module catalogue — not against a feature list.
The proxy's entire request path is a host lookup and a forward. Its handler takes the request's host, finds a target in a table, and either answers a named 404 or hands the request to the reverse proxy. There is no authentication check, no source-address check, no redirect handling and no middleware chain anywhere in the program.
The table is the reason this is structural rather than a missing feature: it maps host → one target, and the lookup strips the port and lowercases the host. A host cannot be routed two ways.
The design is deliberate as far as it goes — "a route hands back a name, not a credential" — but that governs the route grant. It says nothing about what a request arriving at that name is allowed to do, which is what the live configuration relies on.
What the predecessor actually relies on, counted
Two sources, because neither alone is complete: the module catalogue, and the ingress's own dynamic configuration on the node. The catalogue misses what was hand-written on the node; the node's directory misses what modules declare as container labels. An earlier version of this report read only the latter and undercounted as a result.
1. Basic authentication — three dependents in the catalogue
| Module | What it is the only gate on |
|---|---|
| the key-value store | its browser UI, which has no login of its own |
| the relational store | a database web UI |
| the ingress itself | its own dashboard — twice, counting a desktop flavour |
Every one is a credential-less admin surface whose sole protection is a middleware the mesh's proxy does not have. The database web UI is the worst of the three, and the ingress dashboard means the ingress is currently protecting itself with a mechanism its replacement lacks.
2. Outright refusal on a path — an incident mitigation
One hand-written rule on the node blocks external access to an internal API path on the forge. Its own header records it as incident response to a compromise, closing the write primitive that was abused. It is expressed as an allow-list containing a single documentation-range address — that is, a deny-everyone — and the middleware is named accordingly.
It is not an address-scoped allow-list in any useful sense, and reading it as one points at the wrong fix. What it needs is the ability to refuse a request outright, scoped to a path.
The same header already records where this belongs: "not mesh-managed. Durable home is the route-proxy module; re-home when convenient."
3. Path-scoped routing with priority — and this one gates the others
That rule matches a path prefix on a host that is already routed elsewhere, and carries an explicit high priority so it shadows the ordinary route. The mail module needs the same shape for a different reason: it routes a certificate-challenge path on a host that otherwise goes to the mail front end.
Because the table maps a host to exactly one target, neither is expressible today, and adding authentication and a source filter would not make them so. Path scoping with priority is a prerequisite for the refusal rule, not a feature beside it.
4. Redirect rules — live, and they fail quietly
Two routes canonicalise a www name onto its apex with a rewriting redirect. They appear in the
node's configuration and not in the catalogue, so a catalogue-only survey misses them. They are
the easiest of the four to lose, because losing them produces no error — just two public names that
quietly stop redirecting.
What compared cleanly, and is not part of this issue
- Large and streaming request bodies. Four modules raise or remove the body cap — the object store, the file-sync application, the image registry. The standard library's reverse proxy streams with no default cap, so this needs nothing added.
- Connection upgrades, used by at least one console route: native to the standard library's reverse proxy. Not yet verified live against this proxy, but not absent by design the way the four gaps above are.
- Certificate issuance. The proxy refuses to certify any name the mesh did not route, and defaults to a staging issuer until a node opts in to production (issue 004) — stricter than the hand-maintained configuration it would replace.
- Several public names for one module. Already solved by the
contributesmany-shape; needs nothing from the proxy.
Why it matters
Under the "at minimum" rule, nothing can be called a replacement for the predecessor's ingress while any of the four is missing — and one of them is a live mitigation for an exploited vulnerability. The two outcomes if it is left unfixed are both bad:
- the affected routes stay on the adopted ingress indefinitely, leaving the mesh running two reverse proxies side by side with no principled division between them; or
- they are migrated anyway, and three credential-less admin surfaces become reachable by anyone who can resolve a name, while a known-exploited path loses the block that was put in front of it during an incident.
Open questions
These are design questions, not implementation details, and the fix should not be written before they are answered.
- Where does request-level policy come from? Today a contribution carries a name and a port. Extending it to carry policy keeps the mesh as the source of truth, consistent with everything else a route already does. A separate proxy-side settings layer keyed by route name decouples policy from the grant but adds a second place to look. The module's own README notes "the contract is the file, not this program", so this is a contract decision and not a property of one reference implementation.
- May a declaration carry a credential? A password hash in a contribution puts a secret in a declaration. That cuts across how the mesh mints and holds secrets, and it should be settled deliberately rather than as a side effect of whichever option is less code.
- Is the right general shape "these four", or something narrower? Authentication, refusal, path scoping and redirects are what the predecessor uses today. Whether route-level policy should be an open middleware surface, or exactly these four and no more, is worth deciding before any of it is written — an open surface is far harder to withdraw than to add.