1. 20 Jul, 2019 1 commit
  2. 11 Jul, 2019 2 commits
  3. 04 Jan, 2019 1 commit
  4. 17 Nov, 2018 1 commit
  5. 30 Mar, 2018 1 commit
  6. 26 Jan, 2018 2 commits
  7. 22 May, 2017 1 commit
  8. 19 May, 2017 1 commit
  9. 17 May, 2017 1 commit
  10. 16 Nov, 2016 1 commit
  11. 03 Jan, 2016 1 commit
  12. 17 Dec, 2015 1 commit
  13. 09 Dec, 2015 2 commits
  14. 22 Nov, 2015 1 commit
  15. 11 Nov, 2015 1 commit
  16. 12 Oct, 2015 1 commit
  17. 05 Oct, 2015 1 commit
  18. 03 Oct, 2015 2 commits
  19. 19 Mar, 2015 1 commit
  20. 17 Mar, 2015 2 commits
  21. 20 Oct, 2014 1 commit
  22. 17 Sep, 2014 1 commit
  23. 06 Mar, 2014 1 commit
    • Tails developers's avatar
      Start Tor Launcher and time syncing concurrently. · ed6e9f3c
      Tails developers authored
      Having Tor Launcher block will leave it and Tor in a deadlock if the
      system clock is way off. The time syncing stuff has to run in parallel
      to deal with that.
      
      Unfortunately, in some situations the time syncing script may restart
      Tor, which will make Tor Launcher lose its control port connection,
      leaving it with a dead progress bar. These are:
      
      1. We failed to get a consensus. In this situation nothing works well
         any way, so whatever we do isn't much of a regression.
      2. We get a consensus, but the system time is outside its interval.
         In this case we're guaranteed to make Tor work.
      
      The best we can do at the moment seems to be to to simply kill Tor
      Launcher, and ensure that it won't restart upon reconnect. At least
      that deals with 2 in pretty nice manner, while 1 isn't any worse off
      really.
      ed6e9f3c
  24. 05 Mar, 2014 3 commits
  25. 04 Mar, 2014 3 commits
  26. 30 Nov, 2012 3 commits
  27. 15 Nov, 2012 1 commit
    • Tails developers's avatar
      Create wrappers for (re)starting Tor and Vidalia. · a3b52392
      Tails developers authored
      If Vidalia is running, and Tor is restarted, then we also want to
      restart Vidalia. This is because Vidalia doesn't re-connect to Tor
      automatically, so the user has to restart it to be able to control Tor
      again. Also, any options set by Vidalia will be lost since they
      weren't written to torrc, which causes Tor to reach an inactive state
      if it's restarted in "bridge mode".
      a3b52392
  28. 30 Nov, 2011 1 commit
  29. 02 Oct, 2011 1 commit
    • Tails developers's avatar
      Set time from Tor consensus unless it's already in the valid interval. · 58e1b1a3
      Tails developers authored
      This is based on ideas from Liberte Linux' tordate script,
      and meant to implement
      https://tails.boum.org/todo/remove_the_htp_user_firewall_exception/
      
      This allows greatly simplifying the 50-htp.sh NM hook: no need to do fancy
      tricks with /etc/hosts anymore.
      
      Split out and re-order NM hooks:
        First, setup the firewall.
        Then restart Tor.
        Then set the time using Tor consensus, and start HTP (non-blocking) in the background.
        Eventually, restart and cleanup everything that needs to: ttdnsd, pdnsd,
        Vidalia, etc.
      
      Doing so allows us to stop passing a tiny DNS timeout to htpdate / wget anymore:
      commit e291af5d, that introduced this "-t 1" option, explains why it was added.
      These reasons don't stand anymore: the IPs of the server queried by htpdate are
      not in /etc/hosts nowadays.
      
      Non-blocking htpdate has an initscript (/etc/init.d/htpdate, that should not
      start on its own); its options were moved to /etc/default/htpdate.
      
      The tails-htp-notify-user script is removed: no need for feedback as this is now
      non-blocking and does not prevent actual usage. A bit more KISS does not hurt.
      58e1b1a3