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

Quoting anonym (#8263#note-1):

In our Live system context, where a lot of stuff is in tmpfs:es, looking
at the values of free or /proc/meminfo alone isn't accurate for
determining how much memory "really" is free, since the tmpfs usage is
included in the buffers. Hence, MemFree is the lower (and safe) bound of
how much "really" free memory we have, and MemFree + Buffers + Cache is
the upper (and unsafe) bound. The true value should be (at least closer
to) MemFree + Buffers + Cache - (sum of usage by tmpfs:es). We should
check once against that value instead.

The 300 MB magic number (minimum "real memory" available) was found
after bisecting with an ISO built from current feature/jessie:

 * with 278000 kB of "real memory" available, Tails Upgrader could
   successfully tell me that no upgrade was available (which is indeed
   the case), or that I should manually upgrade (after tweaking
   /etc/os-release; because I started from DVD);
 * with 255000 kB of "real memory" available, the check for upgrades
   failed and the desktop session froze;

=> so 300x1024 kB should give us a small safety margin.

For the record, a VM with 1GB of RAM allocated (891 MB visible due to
the QXL video adapter stealing some) on current feature/jessie has
336MB (137MB free + 39MB buffers + 212MB cache - 52MB tmpfs) of "real
memory" available once Tor is ready and Tor Browser is started, so in
practice any system that's beefy enough to use Tails 2.0 can check
for upgrades.

Closes: #10540, #8263

This reverts commit 01c88c1b.

Refs: #8263

Since then, we've bumped the memory requirements (both in our
documentation and on the test suite's "hardware") to 2 GB, so the
original reason for this change has gone away => let's go back to
a value that was tested and confirmed to work (as in: allow upgrading
a running Tails) on Wheezy, instead of a value that was tested on
Jessie, but only for checking for available upgrades.

The follow-ups will be:

 * the cool ideas posted on
   https://labs.riseup.net/code/issues/8263#note-1 will become a new,
   dedicated ticket (that has no reason to block the Tails 2.0 release);

 * #8083 and #7986 will tell us if the value this commit reverts to
   is OK.

Have the security check and the upgrader wait for Tor having bootstrapped with systemd unit files ordering.

Two less ugly while/sleep loops, two.

At least in Jessie, this value is generally around 75 MiB in the
automated test suite, preventing the upgrade check from
happening. It's been lowered to an arbitrarily chosen 32 MiB, but I
wonder if we can remove that check completely. After all, the
available memory + buffers + cache should be what actually matters.

In particular, Archive::Tar::Wrapper, when called by tails-install-iuk, wants to
chdir back to the original cwd after it has chdir'd elsewhere to do its job.

... and accordingly update the design document and manual test suite steps.

The tails-upgrade-frontend program is run as the tails-upgrade-frontend user,
that is basically equivalent to root. Some of the available
tails-upgrade-frontend options might be dangerous. I've looked at it quickly and
didn't find anything scary, but still, it's simply not worth taking the risk of
privilege escalation, persistent root kit implementation, and so on.

Strictly speaking, this change does not really belong to
bugfix/7345-upgrade-from-iso-from-1.0-to-1.1, and could have been implemented
separately. However, this branch introduces running as root a syslinux binary
taken from the installed IUK, so it raised the flag that made me want to lock
this down a bit more.

The general goal is to avoid displaying "Not enough memory available to check
for upgrades" too often due to over-cautious memory requirements checked in
the wrapper.

The specific goal is to avoid having to bump the hardware requirements for
Tails 1.1 (Wheezy) to >> 1 GiB of RAM, as this would 1. not be very nice for
users of oldish hardware; and 2. force us to implement #5502 ("Notify user if
hardware requirements are not met") in time for the 1.1 freeze.

My experiments, documented on #5390, indicate that even lower limits would
probably work. Let's not be too adventurous to start with, though: my plan is to
lower the limit to something that is low enough for the wrapper to dare running
the check for upgrades, but still quite cautious.

Later on, we could try lowering the limits even more, or even drop it entirely:
this would require a mechanism to detect when the check for upgrades fails due
to memory exhaustion, which don't have yet.

Note that, if an automatic upgrade is available, Tails Upgrader checks memory
again, to ensure there's enough free memory to apply the upgrade. This commit
assumes that Tails Upgrader's own check is cautious enough, and that we were not
implicitly relying on the check done earlier, in the wrapper, to ensure upgrade
safety. This assumption might be wrong. My plan is to use the incremental
upgrade to 1.1~rc1 as a test bench to verify this, as I have no time to fully
test this fully right now (still, I successfully applied a small — 50 MiB —
IUK on top of a current build from this very branch, with 126 MiB of free
memory, and 700 MiB total free memory).

The symptom of a failed upgrade due to lack of memory (and then, of a too low
$mem_factor value in Frontend.pm) would be to see the upgrader that simply die
in the middle of the download, or (worse) in the middle of the upgrade. In the
worst case, the resulting (partially upgraded) system may not boot anymore, but
no user data will be affected, and the user can still fix their stick by doing
a full upgrade.

Remove period after URL, for consistency with other messages from the Upgrader and easier copy'n'paste.

We run many things in parallel at session startup, and in some cases we are not
able to check for upgrades due to memory exhaustion. Waiting a bit might help.

Run tails-update-frontend as a dedicated user, and don't allow the amnesia user to install any arbitrary IUK.

The actual limit was determined experimentally, and may have to change a bit in
the future.

This will make debugging easier.

Wait for the /var/run/tordate directory to appear before trying to watch it
with inotify.

Avoid filling "disk", i.e. RAM, with error messages sent in endless loop in
~/.xsession-errors when no network connection is up.

I.e. wait to be sure that time is in Tor valid range,
rather than for HTP success.

This made sense when Tor was restarted after htpdate finished. These have been
re-ordered, and we are know guaranteed to have web access when htpdate has
finished.