GitLab

... to spawn a terminal instead of the greeter, which makes it easier to
debug it.

Closes #17084

… otherwise, it can't delete files that will be installed by hooks
which are run later.

We don't need them in the initramfs, let's save some space.

refs #17320, #18188

We only need them at build time, for
config/chroot_local-hooks/58-create-tails-website-CA-bundle.

There's no reason we should fiddle with the system-wide CA store.

refs #18127

refs #18098

There is no user interaction or significant delay between this message
and the network connection being disabled.

thanks for the input sajolida! see !284

Spotted by perlcritic.

Fixes regression introduced in 3b737d51.

refs #18051

The "/2" division confused sajolida:
tails/tails!305 (comment 162385)

This is what we're doing in our Installer. Incidentally, it also implies
the unit we're displaying is the correct one (although it's ambiguous
but we've decided to do as everybody else and live with it).

Outside of Tails, socks5:// would lead to DNS leaks. This does not matter in the
context of Tails: the system DNS resolver is torified, and on top of that we
have firewall protections against DNS leaks.

I'm going to propose we stop supporting our htpdate fork outside of Tails.

Unfortunately, this is not very helpful, given how curl handles errors
when one uses --socks5-hostname.

For example, upon DNS resolution error:

 - with --socks5-hostname:

   curl: (7) Can't complete SOCKS5 connection to nope.puscii.nl. (4)

   ⇒ We don't learn anything useful.

 - with torsocks and without --socks5-hostname:

   1608286055 ERROR torsocks[1351008]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:677)
   curl: (6) Could not resolve host: nope.puscii.nl

   ⇒ We learn that the problem is about DNS resolution.

Nowadays we only download the HTTP headers.

I suspect that displaying a size in MiB, claiming it's GB, will confuse users :)

And use GB consistently. See #15104.

It's unclear to me why we needed this patch:

    https://bugzilla.mozilla.org/show_bug.cgi?id=1680483

... which it hasn't been depending on for over six years. :)

I also had to clean up some debugging code that depended on yelp in
persistence-setup, which does not seem like a good enough reason to
keep including it.

Otherwise, if Tor Browser is not running, then this process is turned
into the Tor Browser process, which is not ideal when called from a
notification (which we do in several places) since its code then
cannot exit until the Tor Browser process exits, using resources
unnecessarily.

"Don't Show Again" seems to be the usual phrasing for such things.

Since Tails 4.13 when a user has disabled persistence, or plugs
another Tails with a TailsData partition, and tries to mount TailsData
through Nautilus, they are met with an error: 'This location could not
be displayed. You do not have the permissions necessary to view the
contents of "TailsData"'. This is due to #7465 (!210) where we indeed
made the TailsData root world-non-readable, and did not consider this
use case.

Note that this change indeed changes the permission, which might seem
dangerous, but if the Tails is later booted it will self-heal, so all
is ok.