From 23ed835e00e3c059f4376e8e7380b3832e0b6b57 Mon Sep 17 00:00:00 2001 From: mrambossek Date: Sat, 1 Aug 2026 22:17:55 +0200 Subject: [PATCH] docs: record that a revived beacon belongs in the web UI, not its own listener Its Python service wildcard-bound 0.0.0.0:443, which is what silently compromised the reserved measurement address. Two routes on the admin UI would inherit the TLS and certificate already in place, need no extra port, and pick up authentication the standalone receiver never had. Co-Authored-By: Claude Opus 5 --- docs/build-status.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/build-status.md b/docs/build-status.md index 0668dff..e62d7b1 100644 --- a/docs/build-status.md +++ b/docs/build-status.md @@ -1163,3 +1163,20 @@ the very name the certificate is issued to. sshd likewise now listens on `.150`, The point of all this: `fmr.echo-lot.app` gains an A record, so the server stops being reachable only over IPv6 — which is what made it unreachable from a phone with no working IPv6, presenting as "this host does not exist" in two different browsers. + +### If the beacon comes back, it belongs in the web UI + +Not as a separate listener. The receiver being its own Python service on `0.0.0.0:443` is exactly +what silently compromised the reserved address, and a second process racing for a port is a +recurring problem rather than a one-off: whoever loses the race simply fails to start, and on a +reboot which one that is comes down to unit ordering. + +Folding it in costs little and settles several things at once. It would be two routes on the admin +UI (`POST` the observed adb port, `GET /apk` for the staged build), behind the TLS the UI already +terminates and the certificate it already renews, with no extra port and no wildcard. It also gets +authentication for free — the current receiver accepts a port report from anyone who can reach it, +which is tolerable for a dev tool on a trusted network and not something to keep once it lives +beside an admin session. + +The one thing that changes on the device side is that the POST becomes HTTPS. That is a real +certificate rather than a self-signed one, so it costs a URL scheme rather than any trust plumbing.