A loopback tab that can see its own fleet: the directory, and self-enrolment

[karngyan]

The last two steps of "install flue on Mac A, deploy the relay, pair a phone,
install flue on Mac B, run the join line" work today. What did not work was the
step nobody thought to check: a machine's own loopback browser had no fleet
identity and could not even read the fleet directory. Both machines correctly
joined, both on the relay, both holding the fleet key — and each one's own tab
showed a fleet of one.

Two endpoints, both loopback-only, both behind withAuth.

Why a loopback tab could see nothing, and what CSP had to do with it (nothing)

readDirectory fetches https://<relay>/directory cross-origin from the tab
on http://127.0.0.1:7717. The Worker sends no Access-Control-Allow-Origin
on any route — grep -rn "Allow-Origin" relay/ has zero hits, and
/directory answers carry JSON_NO_STORE and an ETag and nothing else. So
the browser rejects the promise before a byte of the body is readable, and
readDirectory folds every fault into NOTHING, by design — the failure
surfaces as "no machines" and never as an error.

CSP was not the blocker, and that is worth saying plainly because it is where
the search naturally starts: LocalCSPFor already puts the relay origin in
connect-src, for exactly this fetch. CORS was the blocker, and it is not a
policy the daemon can relax from the far end.

Every existing test missed it because every fleetSources test injects
directoryFetch — the one code path a real browser takes was the one path
nothing exercised.

Why a daemon-side proxy rather than a header on the Worker

GET /api/fleet/directory has the daemon make the read on the leg it already
holds and hand the relay's answer back verbatim. Preferred over
Access-Control-Allow-Origin: * on the Worker because:

• it works against relays deployed by an older flue, where the header would
  need a flue relay update on every fleet before loopback tabs came right —
  and until then the failure is the same silent "no machines";
• it adds nothing to the relay's public surface: the bytes go to a caller
  already authenticated on loopback, rather than to every origin on the
  internet.

The Worker header is arguably still worth adding as a complement — it would let
a relay-served bundle use the route without a daemon in the path — but it is
deliberately not in this PR.

Verbatim is the security property, not a shortcut. The browser goes on
verifying every blob under the fleet public key it pinned, so the daemon is
transport and never trust. Directory.Snapshot sits beside ingestSnapshot
and shares nothing with it: no verification, no counts, no sink, no cached
ETag (the caller needs a body every time, and the cached tag is a claim about
what this process has applied — a different question from what the browser
has seen).

GET-only, so methodPolicy is untouched. A daemon with no relay leg answers
404; one whose relay refused answers 502, so the browser can tell "no fleet"
from "fleet unreachable".

Self-enrolment, and the no-new-authority argument

POST /api/fleet/enrol: the browser sends its device public key, the daemon
does FindByKey first (a browser calls this on every load, so it has to be
idempotent — Devices.Add deliberately is not), else mints and Adds, and
answers with the device id, the device certificate, the fleet public key
and this machine's id.

The argument survived review, and the code makes it stronger than the prose
did. Verified before building:

• wire.Spawn passes m.Cmd to registry.Spawn as argv
  (internal/daemon/conn.go:514), and registry.start runs
  exec.Command(argv[0], argv[1:]...) (internal/session/registry.go).
• So any client that can open /ws on loopback can already
  cat ~/.config/flue/relay.json, read the fleet seed, and mint certificates
  for the entire fleet without asking this daemon anything.
• This endpoint collapses three steps into one for the honest case and changes
  nothing for the dishonest one. The credential that gates it — the session
  token, through withAuth — is the credential that gates the shell. There is
  no configuration in which this is reachable and that is not.

HTTP, never the wire protocol

This is the load-bearing decision. A wire.Enrol message would be reachable
from every relay-origin device, because the wire protocol is exactly what a
relay forwards — and it would let any already-admitted device mint a fleet
certificate for a key of its choosing. That is a real escalation: admission
to one machine becomes manufactured admission to every machine, for keys nobody
has proved they hold. The argument above does not cover it, because a
relay-origin device cannot read relay.json. internal/daemon/relayui.go
already codifies "loopback-only surfaces get no wire equivalent" for the
Cloudflare token; this follows it, and says so in the doc comment so the next
person reaching for symmetry meets the reason first.

internal/transport/local needed no change — verified, not modified

withAuth's checkProvenance already refuses:

• a co-resident loopback port — a page on http://127.0.0.1:3000 sends that
  Origin (not on the allowlist) and Sec-Fetch-Site: same-site (only
  same-origin or absent is admitted);
• DNS rebinding — the Host allowlist is 127.0.0.1:<port> and
  localhost:<port> and nothing else.

And methodPolicy answers every OPTIONS 405, so no CORS preflight can ever
succeed and no cross-origin JSON POST can be made at all. Not one line of that
package changed.

Three details worth naming

• The row is labelled <hostname> — this machine's browser. Stated
  plainly because it will surprise: after this, machine B's Devices screen
  lists A's browser on first contact, via AddFromFleetCert. That is correct
  fleet-trust behaviour and exactly the sort of row an operator would otherwise
  squint at, so the label says whose browser it is. The certificate carries the
  same name, so a sibling writes the same label.
• Revoking it does not lock the machine out of its own UI. A loopback
  connection authenticates a machine-local session token rather than a device,
  so it carries device == "", addConn files it under no device bucket, and
  disconnectDevice walks that bucket and finds nothing. Tested end to end:
  connect a loopback tab, enrol, revoke over wire.Revoke, and the tab is
  still up and a fresh one still connects.
• A revoked key is refused rather than re-enrolled. FindByKey answers
  "not found" for a revoked key and Devices.Add does not consult the
  revocation list at all, so without an explicit IsRevoked check the next
  page load would resurrect a device the operator had just cut off — a fresh
  row on every Devices screen for a key both acceptance paths still refuse. A
  revocation permanently outranks a certificate; un-revoking is a new key,
  which for a browser means clearing its storage. Mutation-checked: disabling
  the guard turns that test's 403 into a 200 and a new registry row.

A daemon with no fleet key, or with one and no machine id on the relay, answers
409 and writes nothing rather than half-enrolling — the same refusal the
pairing ceremony makes, for the same reason: a cert naming the empty machine is
one no reader can attribute.

Endpoint shapes

GET /api/fleet/directory — behind withAuth, GET only.

• 200 — the relay's {"v":1,"entries":[{"key","blob"}]} byte for byte,
  Content-Type: application/json, Cache-Control: no-store
• 404 — no relay leg on this daemon
• 502 — relay unreachable or refusing
• 401 / 403 — unauthenticated / cross-origin

POST /api/fleet/enrol — behind withAuth, on methodPolicy's postable
list.

• request: {"publicKey": "<32 bytes, standard base64>"} (no label — the
  daemon names the row)
• 200 —
  {"deviceId": string, "deviceCert": base64, "fleetPub": base64, "machineId": string},
  Cache-Control: no-store. The []byte fields are standard base64 with
  padding, matching the pairing answer's deviceCert.
• 400 malformed body or key · 401 no session token · 403 revoked key or
  cross-origin · 409 no fleet key, or no machine id · 503 no device
  registry · 405 any method but POST

Test evidence

18 new tests in internal/daemon/fleet_test.go, 5 in
internal/transport/relay/directory_test.go (on the existing dirFixture /
fakeDirectory harness).

make web relay                            ok
go build ./... && go vet ./...            clean
gofmt -l ./cmd ./internal                 only the two files already unformatted on main
go test ./...                             ok (all packages)
go test -race ./internal/crypto/... ./internal/transport/... ./internal/fleet/...   ok
go test -race ./internal/daemon/          ok

Stage 1: 404s with no relay leg; returns the relay's bytes unchanged with one
(asserted on the bytes, including odd whitespace and an unknown field, because
a re-encode would break every signature in the document); 401 unauthenticated
and 403 cross-origin, with the relay not dialled in either case; 405 on POST.
Transport side: the blob survives the round trip, the sink is untouched, the
daemon secret rides along, the read is unconditional, and both a refusal and an
unreachable relay error rather than answering empty.

Stage 2: the certificate verifies under the fleet public key from the same
answer and names the key, the label and the machine id; re-enrolment returns
the same device and the same certificate bytes and leaves one row; the seed
never appears in the answer in any encoding and fleetPub is 32 bytes; refused
without the session token, refused with a bad Origin, refused by GET, refused
for a revoked key, refused on a daemon with no fleet key and on one with no
machine id — each with nothing written to the registry; the row appears with
its label; revoking it leaves the loopback tab connected.

No web sources were touched. web/src/fleet/fleet.ts, web/src/crypto/keys.ts,
internal/daemon/conn.go and internal/wire are untouched — a later stage
wires the browser against these two endpoints.

🤖 Generated with Claude Code