Setup wizards offer a faster clearnet first sync that the default egress firewall makes inert

[pithead-developer]

Found while resolving #2649.

After #2649, apply passes monero.clearnet_initial_sync / tari.clearnet_initial_sync to the daemons only while network.tor_egress_firewall is false. Before that change the flag was already defeated by the default-on firewall (#941), and after #2472 it left monerod peerless.

Both setup wizards still offer the faster sync but leave the firewall at its default (on), so the choice has no effect:

• CLI: lib/pithead/24-config-wizard.sh asks "First sync: fully private over Tor (days), or faster over clearnet (hours)?" and sets only the two clearnet_initial_sync flags.
• Appliance first boot: dashboard/mining_dashboard/web/static/wizard/setup.mjs offers "Faster, over the open internet — Takes hours", and wizard/form.py writes the same two flags. network.tor_egress_firewall is a host-only key and the appliance has no shell, so on the appliance the option can never take effect.

docs/getting-started.md and docs/appliance.md now say the faster sync needs the firewall off, and the appliance row says it syncs over Tor either way.

Decision needed: remove the option, have the wizard also turn the firewall off for the sync window (and back on after the #234 transition), or keep it and say in the prompt that it is inert while the firewall is on.

The dashboard confirm gate classifies the rendered .env diff. With the firewall on, a dashboard commit of the flag changes nothing that runs, so it commits without a typed APPLY. When the host later turns the firewall off, its apply preview does show the CONFIRM exposure row.

[pithead-developer]

Questions before work continues (answer here, then remove the question label):

1. Which fix for the faster clearnet first sync offered by both wizards: (a) remove it, (b) have the wizard also turn network.tor_egress_firewall off for the sync window and back on after the Auto-transition clearnet initial sync back to Tor once synced (follow-up to #183) #234 transition, or (c) keep it and say in the prompt that it has no effect while the firewall is on? My default is (a): remove it from the CLI wizard (lib/pithead/24-config-wizard.sh), the appliance first-boot wizard (setup.mjs and wizard/form.py) and their tests. Operators on a DIY host can still set the two flags and the firewall by hand, as docs/getting-started.md already describes, and the appliance could never use the option because it has no shell to turn the firewall off. I would not take (b): it opens the whole stack's egress, not just the P2P port, and it needs the Auto-transition clearnet initial sync back to Tor once synced (follow-up to #183) #234 supervisor to restore the firewall. That is a larger, security-sensitive change than this bug asks for. I would not take (c) either: a first-boot choice that does nothing is still misleading. Do you agree with (a)?

2. Should this work start only once PR fix(render): ignore clearnet_initial_sync while the egress firewall is on; run the clearnet scenario with it off (#2649) #2679 (tier4-e2e matrix: local-pruned-main-clearnet-sync never writes the clearnet→Tor marker after the develop merge of 2026-09-24 (job 987) #2649) has merged into develop, since the wizard text and tests have to match its firewall-gated render? My default is yes: once you answer, I branch from develop after fix(render): ignore clearnet_initial_sync while the egress firewall is on; run the clearnet scenario with it off (#2649) #2679 lands, and if it has not landed I return blocked on tier4-e2e matrix: local-pruned-main-clearnet-sync never writes the clearnet→Tor marker after the develop merge of 2026-09-24 (job 987) #2649 rather than stacking this on its unmerged branch.

3. If the option is removed, should wizard/form.py drop the clearnet_sync form field without a trace, or keep reading it for an old cached wizard page? My default is to drop it, because the form is served with the dashboard build and there is no stale client to support. Is that right?

[pithead-developer]

Answer

1. Yes, (a): remove the faster-clearnet option from both wizards and their tests. It matches the tier4-e2e matrix: local-pruned-main-clearnet-sync never writes the clearnet→Tor marker after the develop merge of 2026-09-24 (job 987) #2649 ruling (the flag reaches monerod only with the egress firewall off, which the appliance cannot do), and a first-boot choice that does nothing is worse than none. Not (b): opening the stack's egress from a wizard is a security change this bug does not ask for.
2. Yes: branch from develop once PR fix(render): ignore clearnet_initial_sync while the egress firewall is on; run the clearnet scenario with it off (#2649) #2679 has merged; if it has not, report blocked on tier4-e2e matrix: local-pruned-main-clearnet-sync never writes the clearnet→Tor marker after the develop merge of 2026-09-24 (job 987) #2649.
3. Drop the form field outright; there is no stale client to serve.

[pithead-developer]

Blocked on #2649. Per the operator's answer, work starts from develop only after PR #2679 (#2649) merges; it is still an open draft, so nothing is branched or edited yet. Once #2649 closes, I'll take option (a): remove the faster-clearnet choice from the CLI wizard (24-config-wizard.sh, then rebuild the CLI) and from the appliance wizard (setup.mjs, and drop the form.py field outright), update the tests for both, and correct getting-started.md and appliance.md.

The runner resumes this issue when that one closes.