GitLab

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

E.g. for our custom/undocumented (but so far unused)
`--force-net-config` option.

The path hasn't existed for a long while, and places.sqlite hasn't
been created there for even longer.

It feels like it belongs better in the script where we actually start
Tor Launcher than the wrapper that makes root invoke it in the way we
want. Also, we have to think less about how sudo propagates
environment variables so we can simplify its setup.

... where we have the Tor Browser. For consistency.

Let's not pretend the current script is similar to what upstream would
use, since it has Tails specific stuff in it.

... instead of the crazy workaround we had to use before. It turns out
you *can* use -app and -profile together, but only if -profile is
given last. It may be that it was fixed recently, because I'm pretty
sure it didn't work last time I wroked on this.

Also, in /usr/share/TorBrowser/Data/Browser (which is the "default"
profile directory relative to the Tor Launcher applocation.ini file)
the Caches directory must exist and be accessible for the tor-launcher
user even if -profile is used, so we just have to ensure it exists.

Will-fix: #7943

This is what we do everywhere else in our code base.

refs: #10684

`systemctl daemon-reload' is a very big hammer: while it's running, socket
activation, D-Bus activation, and more systemd functionality are disabled.
In this case, as long as we use only systemctl {stop, disable, mask}, then we
don't need to do a global daemon reload, so let's not take the risk.

Earlier we already ensure that Tor has bootstrapped, which implies
that the control port must be up.

Otherwise Vidalia will be running and showing errors while we make
sure that Tor bootstraps, which could take a while.

Refs: #10658

Refs: #10658

Refs: #10658

Refs: #10658

Refs: #10658

Refs: #10658

Refs: #10658

Refs: #10658

It uses no variables currently, but let's get ready for the future.

Refs: #8064

Jessie's zenity does not wrap it itself.
Same in sid with 3.18.1.1-1 by the way.

This should help debugging e.g. #9012.

As explained on https://labs.riseup.net/code/issues/8328#note-5, it's
been broken for 16 months, it is still broken after the partial fix that
went in Tails 1.6, and the logic on which the detector is based cannot
work anymore. Reintroducing and porting this feature is now tracked
on #10560.

Closes: #8328
Refs: #10560

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

... and move tails-wait-until-tor-has-bootstrapped.service from
default.target to it. The main effect is that anything that wants to
start after graphical.target or multi-user.target does not have to wait
for Tor to have bootstrapped (which could very well never happen, e.g.
when working offline) anymore.

Will-fix: #9393

Tor 0.2.7.x packaging now uses a template systemd unit file,
and the instance we use is called tor@default.service.

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

Suggested by anonym -- thanks!