1. 03 Mar, 2022 1 commit
    • intrigeri's avatar
      Have MAC address spoofing ignore veth* devices via udev · 62406585
      intrigeri authored
      This has 2 advantages:
       - Not running tails-spoof-mac when it's not relevant
         addresses the problem at the root and avoids logging
         potentially confusing stuff (at least when udev logging
         is set to debug).
       - The logic we had in tails-spoof-mac to ignore veth*
         never worked for veth0. This fixes it.
  2. 28 Apr, 2021 1 commit
  3. 16 Mar, 2021 1 commit
  4. 08 Mar, 2021 2 commits
  5. 19 Sep, 2020 5 commits
  6. 21 Jul, 2020 2 commits
    • geb's avatar
      Ensure MAC spoofing messages are translated (refs: #17783) · cbb6b631
      geb authored and intrigeri's avatar intrigeri committed
      As tails-spoof-mac is running as root, its messages cannot be translated
      according to the user settings. This commit solves this problem by reading the
      localization settings from the environment (/etc/default/locale) in
      tails-spoof-mac initialization. To make this work, we also set up the desired
      localization environment before launching tails-unblock-network and
    • intrigeri's avatar
      On MAC spoofing failure, include the name of the disabled network card in the... · 56a11b3e
      intrigeri authored
      On MAC spoofing failure, include the name of the disabled network card in the title of the notification
      That was the intention since 988b4186
      but in that commit, we forgot to replace gettext with eval_gettext
      when introducing variables in the translatable string. Let's fix this
      and accordingly, drop the test suite workaround for this bug.
      refs: #17784
  7. 20 Jul, 2020 1 commit
  8. 26 Jun, 2020 2 commits
  9. 25 Jun, 2020 1 commit
    • geb's avatar
      Udev may close child processes when a process associated with a rule · d2a4be58
      geb authored
      (/etc/udev/rules) terminates. As mac spoofing notifications processes
      are launched in background, with a static wait, they may be killed
      before the message is effectively displayed.
      This patch makes tails-spoof-mac wait for those processes before
      exiting. It may makes tails-spoof-mac wait indefinitely. However,
      udev will ensure it terminates after 120 seconds.
  10. 24 Jun, 2020 1 commit
  11. 23 Jun, 2020 1 commit
    • geb's avatar
      Ensure Mac Spoofing Panic message will be correctly displayed (refs: #17779) · 64e7378e
      geb authored
      Udev may close child processes when a process associated with a rule
      (/etc/udev/rules) terminates. As mac spoofing notifications processes
      are launched in background, with a static wait, they may be killed before
      the message is effectively displayed.
      This patch disable the background call of the notifications messages to
      ensure they wont be killed.
  12. 11 Jul, 2019 2 commits
  13. 03 Mar, 2017 1 commit
    • anonym's avatar
      Disable modules we blacklist for security reasons. · 442a293d
      anonym authored
      Blacklisted (via `blacklist MODULENAME`) modules are only blocked from
      being loaded during the boot process, but are still loadable with an
      explicit `modprobe MODULENAME`, and (worse!) via kernel module
  14. 11 Feb, 2016 2 commits
    • anonym's avatar
      Avoid set -u issue when testing if variable is set or not. · 364a3c8d
      anonym authored
      Whenever there's a risk that we will reference a shell variable in a
      script run with `set -u` (including libraries that we sources from
      such scripts) we must reference the variable in a way so it gets a
      default value, i.e. `${VAR:-}` to give it the empty string as the
      default (which is what generally makes sense).
      In particular, it's quite clear that in all cases where we do
      something like `[ -n "${VAR}" ]` or `[ -z "${VAR}" ]`, where an
      expected value is the empty string, which could mean that the variable
      is not initialized, we should give such a default (as the empty
    • anonym's avatar
      Add set -u to all gettext:ized shell scripts. · 74a91c28
      anonym authored
      In gettext-base < 1.8.2, like the one we had in Wheezy, gettext.sh
      references the environment variable ZSH_VERSION, which we do not
      set. This has prevented us from doing `set -u` in all gettext:ized
      shell scripts unless we first initialize that variable before sourcing
      Now that we install a new enough gettext-base, we can finally do this
      and remove the initialization hacks.
      Will-fix: #9371
  15. 30 Nov, 2015 1 commit
  16. 22 Nov, 2015 1 commit
  17. 17 Nov, 2015 3 commits
  18. 13 Sep, 2015 1 commit
  19. 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.
  20. 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
  21. 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
  22. 31 Mar, 2015 1 commit
  23. 25 Mar, 2015 1 commit
  24. 08 Mar, 2015 1 commit
    • intrigeri's avatar
      Wait for ibus-daemon instead of nm-applet, to judge whether we can send notifications. · 5771f243
      intrigeri authored
      We should not be running nm-applet on GNOME Shell, since this functionality is
      nowadays taken over by GNOME Shell itself. And notifications are also handled by
      GNOME Shell, so let's instead wait for a process that's started by GNOME Shell,
      assuming that if it's ready enough to start long-lived child processes,
      hopefully it's ready to receive and enqueue/display notifications.
      Will-fix: #8685 (not really, but let's help Redmine track the relevant commits)
  25. 07 Mar, 2015 1 commit
    • intrigeri's avatar
      Start adjusting waiting for notification facilities for Jessie. · 88de98a1
      intrigeri authored
      It makes no sense to wait for gnome-panel on Jessie: we're not running
      it anymore. Also, GNOME Shell is now providing the notification daemon
      facility, so we don't need to wait for notification-daemon.
      Will-fix: #8685 (Well, not really: as said there, this might not be robust
      enough: best would be to check if the DBus service is ready instead.)
  26. 13 Jan, 2015 1 commit
  27. 12 Jan, 2015 3 commits