Both claims are load-bearing prose, and both are wrong in a way nothing in
the tree reads (#4168).
swarm-nats says the queue is "reachable from every agent container on the
hive" because the container shares the host netns — in a comment, and again
in the operator-facing `calloutUserPublicKey` description, which renders into
the options doc. Agent containers do not share it: `PRIVATE_NETWORK=1` is
written unconditionally (hive-priv/src/main.rs, and hive-priv-sock says
"isolation is the only supported mode"), and hive-network.nix states the
shared-netns mode was removed. The bridge firewall opens 53/67/80/443 plus
`exposeHostPorts`, whose only consumer tree-wide is otel — the queue's port is
in none of them, and no gateway route exists either (`grep -c nats` in
hive-gateway/default.nix -> 0; control `forge` -> 3, so the zero means
something). Its actual clients are host-side: HIVE_C0RE_NATS_URL and
SWARM_CONTROLLER_NATS_URL, both 127.0.0.1 on a single-host swarm, plus each
remote hive dialling a routable address.
swarm-victorialogs says the ingest endpoint has "no authentication of its
own". Upstream offers Basic Auth via -httpAuth.username / -httpAuth.password
(and -metricsAuthKey / -deleteAuthKey / -pprofAuthKey); this module sets none
of it. "The software offers nothing" and "we configure nothing" send a later
reader to different places, so the wording now says the second one.
Neither conclusion changes. The queue must still refuse everyone until the
callout responder exists, and the logs endpoint must still be pinned to
loopback — only the reasons were false.
Checked while here: swarm-authelia's identical "no authentication of its own"
is TRUE (upstream's telemetry.metrics has exactly enabled, address, buffers,
timeouts), and otel.nix's "reachable from agent containers and nowhere else"
is true and better-founded than it claims — the receiver binds the bridge IP,
not just a firewall hole.
Refs #4168.
4bb44daf03