GitLab

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Themes#Documentation
says that "Lightweight themes have been deprecated", which explains why our old,
custom lightweight theme is ignored.

The only options to fix this are:

 - Create our own theme, get it automatically signed by Mozilla on AMO, download
   the resulting XPI, and somehow make it available at build time.

 - Use an existing theme with a GPL-3+ compliant license.

I've chosen the latter option: this theme is almost identical to the one we
had before.

The XPI is 7.7K so I don't think it's worth devising a more complicated
solution than just adding it to Git.

In the Browser Console of the Unsafe Browser, I see:

  Warning: unrecognized command line flag -DISPLAY

Now that Torbutton is integrated in Tor Browser
(https://trac.torproject.org/projects/tor/ticket/10760),
we only have to patch its own localized branding files.

Our previous tweaks, when applied to Firefox 68, made it segfault on startup.

The layout of omni.ja has changed a lot so let's adapt our code.
Besides, there are no localized search extensions anymore
so we can simplify things a bit.

I.e. integrate as code comments all the relevant explanations
that were in commit messages, in the previous non-squashed branch
for refs: #12092.

Terminate GDM's GNOME session after the amnesia user logs in, in order to free memory (refs: #12092)

I've heard rumors that we can drop this hack when we switch to Wayland (#12213).
We'll see :)

We kill it as part of desktop.target, i.e. during the "Applications" phase of
the initialization of the GNOME session. We cannot do this earlier reliably:

 - basic.target is started by "systemd --user" for almost every command run as
   the amnesia user and may thus be triggered too early, at a time when we still
   need GDM's processes.

 - If we do this as part of basic.target, it sometimes happens before amnesia's
   X.Org has started, and sometimes after that, which causes racy behaviour,
   weird bugs, and amnesia's $DISPLAY can be either :0 or :1, which breaks our
   code that relies on that value to be always the same.

We're in no rush to kill GDM's GNOME session super early anyway.

Note that we keep GDM running while we kill its GNOME session,
otherwise, the amnesia user can't unlock the screen:

  Fai...

Sleeping 5 seconds unconditionally harms UX.

The assumption here is that:

 - #9012 was caused by an aufs bug that somehow affects how udev (and the
   kernel?) monitor /etc/modprobe.d/, and make them need time until they notice
   that all-net-blacklist.conf was deleted.

 - The same bug would also affect the "-e" test done by the shell this script
   runs under. That is, it would affect essentially any process that accesses
   /etc/modprobe.d/.

 - So for example, this bug can't be "the inode number of /etc/modprobe.d
   changed between the time udev started monitoring it, and the time we trigger
   a replay of the kernel 'add' events". According to the aufs documentation,
   inode numbers can change when using the noxino mount option, which we do,
   and actually that's been one of my primary suspects when investigating
   #9012.

This will give us UTF-8 support.

Note the switch from raw bytes IO to StringIO: the equivalent of what we used to
do in Python 3 is io.BytesIO(), but that won't work out of the box: the code
we're running prints strings on stdout/stderr, not bytes, and Python 3 knows
the difference. So accordingly, remove decoding of the output, since we get
a string already.

Drop anonym's "showingOnly" patch that was merged upstream :)

Otherwise, it gets lost (or at least I could not find it).
In any case, it does not make sense to print "The error was:"
somewhere and the actual error elsewhere.

Those are the files installed by the greeter, from the master branch of
the greeter repo (commit 2b1facdbe3c4c9f209cdcf3835a9d52a3147b8a8).

All files are copied to the same path they are installed at when
installing the greeter Debian package, except for:

 * The tailsgreeter Python package, which is now installed under
   /usr/local/lib/python3/ instead of /usr/lib/python3, because
   that's where we put our own Python packages.

 * The tails-greeter script, which is now installed in /usr/local/lib/
   instead of /usr/bin, because this script should not be executed by
   the user directly, similar to the other scripts in the lib directory.
   The Exec= path in tails-greeter.desktop is updated accordingly.

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/

The output of findmnt is not glob-expandable -- the [...] suffix is
findmnt's ad-hoc way to represent bind mounts.

Fix-committed: #16821

This should not be necessary and is just placed here as a workaround
until I can figure out the real issue (bug in onion-grater? bug in
stem?).

When working on the Tor Browser 9.0 migration there were issues with
Tor Launcher. It starts and does its initial connection to the control
port where it successfully fetches CONFs etc. When clicking "Connect"
it successfully sends a few more things and disconnects, only to
reconnect immediately later (due to some implementation detail in Tor
Launcher). This reconnection fails:

    [...]
    /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57472, filter: tor-launcher): -> SAVECONF
    /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57472, filter: tor-launcher) disconnected: Client closed its socket
    [ Here comes the reconnect: ]
    /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57476, filter: tor-launcher) connected: loaded filter: tor-launcher
    Final rules: [...]
    Unable to connect to tor. Maybe it's running without a ControlPort?
    /usr/local/lib/tor-browser/firefox-unconfined (pid: 8865, user: tor-launcher, port: 57476, filter: tor-launcher) disconnected: client quit
    ----------------------------------------
    Exception happened during processing of request from ('127.0.0.1', 57476)
    Traceback (most recent call last):
      File "/usr/lib/python3.5/socketserver.py", line 625, in process_request_thread
        self.finish_request(request, client_address)
      File "/usr/lib/python3.5/socketserver.py", line 354, in finish_request
        self.RequestHandlerClass(request, client_address, self)
      File "/usr/lib/python3.5/socketserver.py", line 681, in __init__
        self.handle()
      File "/usr/local/lib/onion-grater", line 629, in handle
        self.controller = self.connect_to_real_control_port()
      File "/usr/local/lib/onion-grater", line 570, in connect_to_real_control_port
        stem.connection.authenticate_cookie(controller, cookie_path=global_args.control_cookie_path)
      File "/usr/lib/python3/dist-packages/stem/connection.py", line 803, in authenticate_cookie
        auth_response = _msg(controller, msg)
      File "/usr/lib/python3/dist-packages/stem/connection.py", line 1055, in _msg
        return controller.msg(message)
    AttributeError: 'NoneType' object has no attribute 'msg'
    ----------------------------------------

But if we just connect yet again, it works, hence the workaround.

Refs: #16356, #15709

Refs: #16356, #15709

Without this e.g. the automated test suite, which will call
export_gnome_env() before gnome-shell is running, will have its
journal polluted with errors about this. This is not the first time I
see this and get worried and waste minutes investigating, so let's
just fix it.

To be consistent with other Tails apps (e.g. additional-software).