fix(deploy): the tunnel's door binds loopback only (P9a)
Review finding: `--http` parsed whatever address it was given and bound it. The door is the plaintext MCP service with a static bearer token; plan 3.9 and the P9a model put a TLS proxy or tunnel in front of a loopback listener, and no decision authorises exposing the books unencrypted. `--http 0.0.0.0:7411` would have done exactly that. `local::tunnel_address` now accepts only a loopback address (127.0.0.0/8 or ::1; `127.0.0.1:7411` stays the default) and refuses anything else with a message naming loopback and why. `server` refuses while parsing, before it takes the lock or binds a socket; `serve` refuses before it starts a host, so nothing is left half-open. The bind-failure behaviour for a loopback address is unchanged (said, not fatal, 3.9), as is the unit's hardening. The test `the_tunnel_door_binds_loopback_only` refuses 0.0.0.0, a public sample address and [::] through `server`, checks no socket or host was left behind, refuses through `serve`, then starts a loopback listener and reaches `books.start` with the bearer. No accounting code, report or figure changes.
This commit is contained in:
1 parent
47951e5734
commit
c8541ea9fc
7 files changed
+156
-29
No files matched your search
@@ -235,8 +235,10 @@ reports `service_user (enforced)` (`server::Isolation`).
|
||||
|
||||
The door is the same HTTP service on a second listener:
|
||||
`--http 127.0.0.1:7411` binds the MCP routes beside the Unix sockets
|
||||
(3.9), and Caddy, Tailscale Funnel or cloudflared puts TLS and the public
|
||||
name in front of it. The bearer token guards every call exactly as on the
|
||||
(3.9), and the address is loopback only (any other is refused before
|
||||
anything binds: the door is plaintext with a static bearer, so the TLS
|
||||
proxy or tunnel belongs in front of loopback); Caddy, Tailscale Funnel or
|
||||
cloudflared puts TLS and the public name in front of it. The bearer token guards every call exactly as on the
|
||||
socket; the tunnel only forwards. The socket's peer-credential check
|
||||
(`OwnerOnly`) is for local callers and does not apply to the loopback
|
||||
door, which is why the bearer and the loopback-only bind matter there.
|
||||
|
||||
Reference in new issue
Block a user