1. 03 Jan, 2016 1 commit
  2. 22 Nov, 2015 1 commit
  3. 01 Nov, 2015 2 commits
    • bertagaz's avatar
      Fix for real the logical bug for real-only persistence. · 5666ebcb
      bertagaz authored
      The problem was not that live-persist must error out when read-only
      persistence is activated rather than issue a warning. In the bug raised
      by #10431, the problem was that it *already did* because it tried to
      make the new persistence config anyway. So fixing #10431 by erroring out
      just lead to the same situation.
      In this case, we don't want to error out but warn out that the migration did not
      happen, and just go on with the boot without trying to migrate anything.
      Will-fix: #10431
    • bertagaz's avatar
      Fix identation. · c1b46347
      bertagaz authored
  4. 31 Oct, 2015 1 commit
    • kytv's avatar
      Reorder · e25b4246
      kytv authored
  5. 30 Oct, 2015 1 commit
  6. 29 Oct, 2015 1 commit
  7. 27 Oct, 2015 3 commits
  8. 26 Oct, 2015 6 commits
  9. 15 Oct, 2015 2 commits
  10. 08 Oct, 2015 1 commit
  11. 07 Oct, 2015 1 commit
  12. 05 Oct, 2015 3 commits
  13. 03 Oct, 2015 4 commits
  14. 16 Sep, 2015 1 commit
  15. 14 Sep, 2015 2 commits
  16. 13 Sep, 2015 1 commit
  17. 11 Sep, 2015 1 commit
    • anonym's avatar
      Avoid use of uninitialized value in restricted-network-detector. · 95de82a5
      anonym authored
      If NetworkManager decides that a wireless connection has timed out
      before "supplicant connection state" has occued, our idea of the state
      is `undef`, so it cannot be used in a string comparison. Hence, let's
      initialize the state to the empty string instead of `undef`.
      Will-fix: #7689
  18. 07 Sep, 2015 1 commit
    • anonym's avatar
      Wait a bit longer before showing the panic notifications. · 60a6a3f9
      anonym authored
      It seems that it isn't enough that gnome-panel and notification-daemon
      is running -- sometimes the notification is still sent "too early",
      and is lost. Without a better solution at hand, let's just wait for a
      static amount of time.
  19. 04 Sep, 2015 1 commit
    • anonym's avatar
      Fix a corner case for the MAC spoofing panic mode. · 5f492526
      anonym authored
      If panic mode failed to disable the specific device that couldn't be
      spoofed (by unloading the module) we disable networking. Previously we
      only stopped NetworkManager. The problem is that NM isn't even started
      at this time, but will specifically be started when we're done with
      MAC spoofing.
      Therefore, let's remove NetworkManager so it cannot possibly be
      Will-fix: #10160
  20. 08 Jul, 2015 1 commit
    • intrigeri's avatar
      Fix panic mode on MAC spoofing failure, bis repetita. · 39bce141
      intrigeri authored
      In the past, we had "exit 1" in there. This problem was identified (#8571) and
      fixed (commit 1b46b5b1) in Tails 1.2.3, by replacing this "exit 1"
      with "return 1".
      Then, while working on another, minor problem (#8687), the "exit 1" was
      reintroduced (commit 4ea050ab) in Tails 1.3.2, presumably because we pasted
      sample code from the ticket, that had been drafted *before* #8571 was fixed.
      Sadly, nobody noticed in time.
      I cannot easily reproduce the bug on Tails/Wheezy (because I lack hardware whose
      MAC address fails to be spoofed there), but I could reproduce it with
      Tails/Jessie ("thanks" to the fact we're currently shipping the buggy 'wl'
      kernel module in there).
      Will-Fix: #9531
  21. 03 May, 2015 1 commit
  22. 29 Apr, 2015 1 commit
    • anonym's avatar
      Remove useless log() instance (Will-fix: #9034). · db77e5b0
      anonym authored
      We haven't sourced the Tails shell library's loggin module, so log()
      is undefined. Since we `rm -f` the file, log():ing if it still exists
      afterwards *should* be pointless, so let's just not do it all.
  23. 28 Apr, 2015 3 commits