1. 22 Nov, 2015 1 commit
  2. 05 Mar, 2014 2 commits
  3. 04 Mar, 2014 1 commit
    • Tails developers's avatar
      Rework how we (re)start vidalia. · 05676de6
      Tails developers authored
      The old behaviour of restart-vidalia sometimes causes a number of
      * Vidalia fiddles with the signal handler for SIGINT and SIGTERM,
        delaying termination for up to several seconds when vidalia has just
        started (before its systray icon goes "green"). In that case
        restart-vidalia will fail to kill vidalia in time to start it via
        lckdo, so it just fails. The old vidalia process finally dies
        sometimes after that failure, leaving the user with no vidalia.
      * If vidalia is running (e.g. after the first network connection has
        completed) then restart-vidalia is called from restart-tor, which in
        turn is called from the 10-tor.sh NM hook. restart-vidalia is
        blocking, so in this situation all execution is blocked until the
        vidalia process is killed, which probably won't happen until the
        *next* network connection. The results of this is that all NM hook
        code after restart-tor is called in 10-tor.sh during a second
        network connection is delayed until the third network conncetion,
        and the third's to the fourth, and so on.
      We fix this by simply SIGKILL:ing vidalia and making sure it's always
      started in the background (non-blocking). In this context, lckdo isn't
      very relevant may just as well drop it.
  4. 22 Nov, 2013 1 commit
  5. 19 Nov, 2013 1 commit
    • Tails developers's avatar
      Deny X auth only after vidalia exits · 14d253a0
      Tails developers authored
      Deny X auth only after Vidalia exits. Else, on some slow hardware, vidalia
      fails to connect to X. That doesn't seem to be critical as a potential attacker
      have no other reason to run code as vidalia than having taken control of the
      vidalia process itself. However, it allow a child process of vidalia to connect
      to X.
  6. 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".
  7. 08 Apr, 2012 1 commit
  8. 30 Nov, 2011 1 commit
  9. 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
      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.