GitLab

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 tor@default.service

Above links, but clickable:

• 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

Is this still necessary?

Would a SIGHUP (aka. systemctl reload tor@default.service) suffice?

Test plan

• Check how this relates to http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/tor/-/issues/40499
• Check if in the most trivial scenario, a SIGHUP is sufficient:
  1. start Tails
  2. close Tor Connection
  3. replace this restart with reload
  4. connect to Tor via Tor Connection
  5. disconnect from the network
  6. wait 15 minutes
  7. reconnect to the network
  8. 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 restart we 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
• 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?"