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.

we could reach 10 veth devices, so let's avoid those messaging spamming
us. Thanks, @anonym!

Spotted by ShellCheck.

geb authored Jul 06, 2020 and intrigeri committed Jul 21, 2020

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
tails-spoof-mac.

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

This will ease my review of !70 and future work on the panic mode
code paths.

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 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.

This reverts commit d2a4be58.

(/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.

This reverts commit 64e7378e.

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.

Currently translated at 17.7% (11 of 62 strings)

Translation: Tails/wiki/src/news/version_3.14.1.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/

Currently translated at 39.0% (16 of 41 strings)

Translation: Tails/wiki/src/news/version_3.11.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/

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
auto-loading.

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
string).

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
gettext.sh.

Now that we install a new enough gettext-base, we can finally do this
and remove the initialization hacks.

Will-fix: #9371

Refs: #10658

It was broken on Tails/Wheezy already (the link to the doc is not
visible, and one of the two possible links was broken anyway), so this
is not a regression brought by porting to Jessie. And on Jessie, due to
bug #7989 these links would not work as-is anyway. It's unclear how this
would be best solved; #10559 has been created to sum up the problem and
track future improvements.

Refs: #7989, #10559

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.

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
started.

Will-fix: #10160

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

Will-fix: #8687

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)

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.)

Without this, the "Network card $NIC disabled" notification is
sometimes lost when MAC spoofing fails.

If macchanger fails we have to treat the situation as undefined. We
can't trust that get_current_mac_of_nic() returns the actual state of
the hardware; perhaps it instead reports the driver's state that was
successfully spoofed but not applied in the hardware?

If we do this, the panic mode code will never be executed, so we will
in fact potentially let the device leak the real MAC address on the
network.