network.tor_egress_firewall=false never disables the #270 firewall (jq // false-coercion)

[VijitSingh97]

Bug

The documented #270 opt-out (network.tor_egress_firewall=false, per the comment in pithead and docs/privacy.md) has never worked — the firewall is always installed regardless of the config value.

Root cause

parse_and_validate_config() read the toggle as:

jq -r '.network.tor_egress_firewall // true'

jq's // (alternative) operator treats false as empty, not just null. So false // true evaluates to true:

$ echo '{"network":{"tor_egress_firewall":false}}' | jq -r '.network.tor_egress_firewall // true'
true

The rendered .env therefore always got TOR_EGRESS_FIREWALL=true, and apply_tor_egress_firewall always installed the rules.

The same latent bug existed on .xvb.tor // true (line ~1883): xvb.tor=false (route XvB donation over clearnet) was silently coerced back to Tor.

Impact

• The Enforce Tor-only egress at the network layer (fail-closed) — stop relying on per-app config #270 firewall opt-out is non-functional. Note the failure direction is fail-safe (firewall stays on), so no one was unexpectedly exposed — but the documented config knob is dead, which blocks legitimate uses (e.g. a deliberate clearnet posture, co-hosting scenarios, and the Benchmark Tor vs clearnet while mining (p2pool / monerod / Tari) — does steady-state mining lose yield over Tor? #256 benchmark's clearnet arm).
• xvb.tor=false can't take effect (privacy-safe direction — stays on Tor — but still broken).

Fix

Null-check explicitly so a configured false is honoured (absent still defaults on / fail-closed):

jq -r 'if .network.tor_egress_firewall == null then true else .network.tor_egress_firewall end'

Fixed in commit d4b5df3 on feat/256-benchmark-harness (reaches develop via the #256 benchmark PR). Filing for tracking + so it's not lost if that PR is slow to merge. Surfaced while validating the #256 benchmark's clearnet arm (firewall stayed up → p2pool got 0 sidechain peers).

Follow-up

• Add a regression test asserting tor_egress_firewall=false → TOR_EGRESS_FIREWALL=false in the rendered .env (and =true when absent/true).
• Audit for any other <falsifiable-bool> // true jq reads.

[VijitSingh97]

Both follow-ups done on `feat/256-benchmark-harness` (reaches `develop` via #293):

• ✅ Regression test — extracted the corrected read into a config_bool() helper and added tests/stack/run.sh coverage: explicit false honoured (firewall + xvb.tor), explicit true, and absent→default. The prior firewall test only exercised apply_tor_egress_firewall reading .env, bypassing the config.json→.env jq that had the bug. Full suite: 386 passed, 0 failed. (commit 9211251)
• ✅ Audit — swept all <bool> // true jq reads; the only two falsifiable ones were network.tor_egress_firewall and .xvb.tor, both fixed. The // false reads (monero.clearnet_initial_sync, tari.clearnet_initial_sync, monero.rpc_lan_access, p2pool.clearnet) are safe — false coercing to the false default is a no-op, and a true value is truthy so it passes through.

Will close when #293 merges to `develop`.

[VijitSingh97]

The fix is already carried in the #256 benchmark-harness branch (PR #293) — gouda's pithead runs the explicit null-check (if .network.tor_egress_firewall == null then true else …), which is what lets the benchmark's clearnet arm actually disable the firewall. This issue stays open to track porting that same fix to develop (where pithead still has the // true coercion at lines ~1621 and ~1970); it resolves when #293 merges.