fix(#701): egress panel no longer reports a phantom clearnet leak for the XvB stats fetch - #702
Merged
Merged
Conversation
… the XvB stats fetch The #170 posture panel and topology view routed the dashboard's XvB stats connection through _xvb_route(xvb_enabled, xvb_tor), so xvb.tor: false displayed it as a clearnet leak. That fetch is unconditionally Tor-proxied (XvbClient defaults tor_proxy to TOR_SOCKS_PROXY, compose-pinned to the bridge SOCKS); xvb.tor gates only the xmrig-proxy donation dial (#166). The route is now TOR if xvb_enabled else INACTIVE, matching the code and docs/privacy.md. Tests that pinned the phantom leak now pin the corrected behaviour, plus an all-knobs sweep asserting the dashboard never derives a clearnet route. Closes #701 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The all-configs sweep asserted NO dashboard connection is ever clearnet. That invariant is broader than #701's claim and breaks the moment a dashboard egress with a legitimate clearnet mode lands (#380's alert-sink LAN carve-out in flight on another branch derives exactly that). Scope the sweep to the Tor-hard-wired clients by name — with a drift guard so a rename can't hollow it out — and pin the topology XvB stats edge as inactive when XvB is off, which only the posture side asserted before. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
VijitSingh97
added a commit
that referenced
this pull request
Jul 21, 2026
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #701.
What
With
xvb.tor: false, the #170 egress-posture panel and topology view showed the dashboard's XvB stats (xmrvsbeast.com) connection as a clearnet leak. That fetch never touches clearnet:main.pyconstructsXvbClientwith notor_proxyargument, so it defaults toTOR_SOCKS_PROXY— compose-pinned to the bridge Tor SOCKS and not operator-blankable.xvb.tor(XVB_TOR_ENABLED) gates only the xmrig-proxy donation dial's per-poolsocks5(#166).docs/privacy.mdalready documented the stats fetch as unconditionally Tor (socks5h, #163) — the panel disagreed with both the code and the docs, which is the exact display-vs-reality failure the #160 audit was about (over-warning direction this time, but still a false report).How
service/egress.py: the dashboard's XvB stats route (egress list entry and topology edge) becomesTOR if xvb_enabled else INACTIVE; the xmrig-proxy donation route keeps_xvb_route(xvb_enabled, xvb_tor). The topology edge now always terminates at thetorhub.xvb.tor: false+ firewall on ⇒ zero leaks, donation dial clearnet-but-blocked). The warning-badge and JSON-serializability wiring tests exercise a real leak config instead (p2pool.clearnet: true+ firewall off).### Fixedentry.Verification
make lintandmake testgreen locally; the exhaustive_KNOBSsweep and frontend topology tests pass unchanged.make test-patch-coveragereports no measurable changed lines (the product-side edits are continuation lines inside thecomponents/edgeslist literals; behaviour is pinned by the updated + new tests).XVB_TOR_ENABLEDfeeds onlyalgo_service.pyand (previously, wrongly)egress.py;TOR_SOCKS_PROXYhas defaults in bothconfig.pyanddocker-compose.yml, so the proxy can't be silently blanked.Note: #697 touches the same file for the webhook/ntfy sinks; whichever lands second takes a trivial rebase (adjacent additions in the dashboard conns/edges lists).
🤖 Generated with Claude Code