Check if we can stop restarting tor in 10-tor.sh
Restarting tor via NM, without coordination with Tor Connection, causes all sorts of trouble.
Here's the code:
# We would like Tor to be started during init time, even before the # network is up, and then send it a SIGHUP here to make it start # bootstrapping swiftly, but it doesn't work because of a bug in # Tor. Details: # * https://gitlab.torproject.org/tpo/core/tor/-/issues/1247 # * https://gitlab.tails.boum.org/tails/tails/-/blob/7fae4a761a06e5a14048baff21e0bdb71a1f7226/wiki/src/bugs/tor_vs_networkmanager.mdwn # To work around this we restart Tor. systemctl restart firstname.lastname@example.org
Above links, but clickable:
Is this still necessary?
Would a SIGHUP (aka.
systemctl reload email@example.com) suffice?
Check how this relates to http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/tor/-/issues/40499
Check if in the most trivial scenario, a SIGHUP is sufficient:
- start Tails
- close Tor Connection
- replace this
- connect to Tor via Tor Connection
- disconnect from the network
- wait 15 minutes
- reconnect to the network
- tor should resume working
Tor Connection waits for direct connection to bootstrap, which times out: actually, Tor as already bootstrapped and is working fine, so it does not need to bootstrap again, but apparently Tor Connection does not know this. Essentially, the
restartwe currently have hides a more fundamental disconnect between the actual status of the tor client and the status of
tails-tor-has-bootstrapped.target; once we don't force a new bootstrap anymore via restarting, the problem becomes visible: in some cases tor has bootstrapped but that systemd target is down, which makes some sense since tor is not usable (we're offline, remember), but is problematic because Tor Connection does not know it should not wait for a bootstrap to happen.
- then Tor Connection retries using default bridges, which successfully bootstraps
- Tor Connection waits for direct connection to bootstrap, which times out: actually, Tor as already bootstrapped and is working fine, so it does not need to bootstrap again, but apparently Tor Connection does not know this. Essentially, the
Trivial scenario, but waiting 2+ hours in order to gain confidence that waiting 15 min is sufficient for the remaining tests: same result as when waiting 15 minutes
Trivial scenario, but with default bridges
Trivial scenario, but with custom bridges
Suspend to RAM and resume 15 minutes later
Disconnect then reconnect from a different network 15 minutes later
Brainstorm more elaborate test scenarios, aka. "what can possibly go wrong if we reload instead of restarting?"
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information