GitLab

Fixes syntax problem introduced in e80f093c.
For some reason I don't understand, the script works either way.

This is in preparation for refs: #17933.

refs !178 (comment 156959)

This fixes an over-eager optimization implement
in 806f17d4.

Closes #17921

On #17199 (and possibly #17228) I've seen breakage that seems to be caused by
udevadm trigger: the Greeter starts just fine, but on login, systemd-logind is
confused about the state of FDs (for /dev/dri/card{0,1}) it passes to X.Org:
when amnesia's X.Org starts, it gets passed paused FDs which makes it abort.
I suspect that's because at least one of /dev/dri/card{0,1} seem to briefly
disappear and come back again when we run udevadm trigger.

So let's try to avoid replaying kernel events for graphics-related devices.

Change the name of the database that will be opened by default (if it
exists) when KeePassXC is started to "Passwords.kdbx".

Previously, that was "keepassx.kdbx", because old KeePassX used that
name, but we decided to embrace the default of KeePassXC now.

Rounds the size of numbers displayed in stderr if is not possible to do an incremental upgrade because there is no free memory or disk space available

... where we persist a different directory than the one we actually we want
to persist, and explain that we can get rid of it once #11529 is done.
e

The argument passed to sort_gpus() looks like this:

  [{'Slot': '00:02.0',
    'Class': 'VGA compatible controller [0300]',
    'Vendor-code': '8086',
    'Vendor': 'Intel Corporation',
    'Device-code': '5917',
    'Device': 'UHD Graphics 620',
    'SVendor': 'Lenovo [17aa]',
    'SDevice': 'UHD Graphics 620 [225c]',
    'Rev': '07'}]

So sorting the list based on whether the Vendor ends with "[8086]" did not do
what we want, i.e. sort Intel GPUs last (which we do because the Plymouth
message will be truncated, and we want to display the most relevant GPUs first,
which usually are not the Intel integrated GPU).

This will be needed for #17902.

I was informed [0] that Tor Browser has re-enabled the Enterprise
Policy mechanism, and that it has a settings for completely disable
update checks, so let's use that instead. Meanwhile, let's drop all
other (obviously ineffectual) ways we try to disable update checks.

[0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40103

We initially released the Greeter persistence feature only for the
Unsafe Browser setting (#17085) since we wanted to wait for a release
candidate to properly test the full feature. And now we have 4.11~rc1
in the pipeline! :)

Fixes #17136.

It must be explicitly enabled via a pref since Firefox 69.

Otherwise the Unsafe Browser complains with this at startup:

    /home/clearnet/.unsafe-browser/profile.default/user.js:24: prefs
    parse error: expected 'user_pref' at start of pref definition

It is disabled in Tor Browser (but there is of course some magic that
makes it work any way) to fix a class of DNS leaks, so we re-enable
it.

This reverts commit 03dd03b8.

The reverted commit contains an unrelated change: disabling the
extension signing hacks. That was supposed to be in a separate commit,
but it's fine to revert it too now that the related patches have been
refreshed.

Otherwise this command fails because "Daemon not running",
and thus we abort our wrapper script and Electrum won't start.

refs #17828

There is no langpack tarball for the 10.x nightly builds, so let's
just skip all other locales and focus on getting the browser starting
for now.

For example, it feels weird that we would encourage users to donate to
Thunderbird about as loudly as we encourage them to donate to Tails.

Besides, the default message is retrieved from the web when Thunderbird starts.
We don't need this extra network activity.

This code has been a no-op in practice since at least Tails 4.0.
We've decided to reject #17276 and investigate what the biggest
problems are for email in Tails with slow/shitty Internet connections:
default'ing to IMAP may, or may not, be part of these problems.

Closes #17276

I see that this is not super obvious, but KeyboardSettingUI.apply()
assumes that the keyboard setting was changed by the user, so it sets
IS_DEFAULT (which is somewhat misnamed, it should rather be
WAS_SET_AUTOMATICALLY (or WAS_SET_BY_USER, with the opposite value))
to false.

When the keyboard layout is changed automatically because the language
was changed, we want to set IS_DEFAULT to true, so we don't call
KeyboardSettingUI.apply(), but directly self._setting.save().

What was missing was the call to apply_layout_to_current_screen(), which
was causing #17794.

the previous behaviour was confusing: changing the language was
changing the keyboard layout in the UI, but not really changing it.

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.

Delegate the discover of interface names to udev, instead of relying
on reading and parsing /sys and lspci ourself, to make the discover
more resilient to missing files, bus agnostic (allowing to discover
non PCI devices like USB ones), and explicit (using udev's own hwdb).