GitLab

Closes: #18017

We don't install this locale, so when we require it to be installed in
the "The Unsafe Browser can be used in all languages supported in
Tails" scenario, it fails.

Follow-up on #17139 and !204.

I had problems with getting this part to apply, but it actually does
the opposite of what we want, so why bother?

From Thunderbird 83.0b3 and this bug:

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

Thunderbird 78.3.3 introduced a regression where a key fetched while
sending email to a recipient that you lack the key for are not listed
so you can "Open details and edit acceptance", requiring to work
around it using the Key Manager.

Reported upstream as:

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

but was apparently a duplicate of:

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

where I found the patch.

Without this patch, the pref mail.identity.default.encryptionpolicy
does not do what it is supposed to.

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

This reverts commit 93c54ddc.

So we enable Memory Hole, finally.

Since Thunderbird has this feature enabled by default (and does not
even offer a way to disable it without patching), they are the
pioneers pushing for this, not us, which was part of our original
reluctance to this feature. Also, with a popular email client like
Thunderbird now supporting this out-of-the-box, as well as
k9 (android), mailpile, Evolution, Mail.app, MailMate, Outlook + GnuPG
extension, the problem with unsupported clients seems less of a
problem.

This silences these recurring messages:

  gpg: WARNING: unsafe permissions on homedir '/tmp/PNkUTRsoxv/dev_gnupg_homedir'
  gpg: starting migration from earlier GnuPG versions
  gpg: porting secret keys from '/tmp/PNkUTRsoxv/dev_gnupg_homedir/secring.gpg' to gpg-agent
  gpg: migration succeeded

To make this work simply on the GitLab CI side, in the tests themselves,
detect the GitLab CI environment and skip the tests that are not
compatible with it.

refs #17940

Build system: drop browser localization descriptions for languages not available in the Welcome Screen

We don't install locales for these languages anymore, since users
would not be able to choose them in the Welcome Screen anyway.

Problem is, the "Unsafe Browser works in all supported languages" test suite
step assumes that we ship locales for each of the languages shipped in
the browser localization descriptions file, so it will occasionally fail
with "Could not find a locale for 'ga-IE:IE' (RuntimeError)" or similar.

To fix this, in the browser localization descriptions, only list languages that
are available in the Welcome Screen, and for which we include locales.

refs #17139

Thanks @emmapeel for the suggestion.

Workaround https://bugs.debian.org/972387.

refs #17576

We don't support anything but Tails in our Installer since a while.

Spotted by noticing the "SE Live" French translation.

This improves l10n and fixes upgrading in languages that have a translation for
the "Clone the current Tails" string.

refs #17982

UX ACK: #16384 (comment 158758)

refs #16384

refs #16384

Otherwise, since /live/persistence/TailsData_unlocked is not readable by the
amnesia user anymore, navigating into the Dotfiles source directory from the
Files browser becomes overly difficult.

refs #7465

refs #7465

We stopped supporting read-only persistence years ago, but there's still some
leftover code here and there. Let's remove it.

refs #17972

refs #17971

refs #17971

This helps in 2 cases:

 - Folks with hearing problems may need this in order to get stuff done
   with audio.

 - Some sound drivers/firmware set the 100% volume pretty low, presumably in
   order to avoid distorted sound. Combined with low-volume recordings,
   this is problematic: on my laptop, I often need to raise the volume to 120%
   or higher.

Closes #17491

We're not sure it's ready for prime-time yet. See #15201 and #13649
for details.

We were considering adding Enigmail 2.2.x for its migration procedure,
but we found it so error-prone that we'll add our own migration
instructions instead.

Bye, bye, Enigmail, we had some good times! o/

Otherwise, Tor Browser take ages to start in Tails: #17896

Takes from tails/torbrowser-launcher.git at commit
30d5132fff6147bed0db2170ae5f025260490dda.

I can't reproduce this problem outside of Tails, hence not upstreaming
this.