GitLab

"Nowadays, the torproject.org website is so focused on Tor Browser that
we should point directly to their homepage."

Ref: #17717 (comment 152083)

Upstream did not want this patch, and we are not applying it any
more. Luckily the default url is https so we are good. :)

In passing, I'm removing a few obsolete ones.

A Japanese speaker (passis12345678) tells us that:

"I don't think any Japanese users would agree that Anthy is better than Mozc.
The accuracy of Mozy's Kanji conversion is clearly superior to that of Anthy.
I’ve never seen or heard of anyone who likes Anthy.
Any Japanese user would be happy to replace Anthy with Mozc."

They also note that ibus-anthy has one advantage over ibus-mozc: it defaults to
Japanese input, while ibus-mozc defaults to alphabetic and the user has to
change the setting to Japanese every time they login. Despite that drawback,
passis12345678 thinks that switching to Mozc is worth it anyway: it's
a one-per-Tails-session annoyance, as opposed to a permanent annoyance while
typing in Japanese.

This would be fixed by fcitx-mozc (which defaults to Japanese), but switching to
fcitx is another, much bigger matter: IBus seems to be much better integrated
into GNOME than fcitx. Let's stick to IBus for now and try this minimal change.

As our kernel hardening page demonstrates, "the Tails kernel has no more special
kernel security feature than the stock Debian kernel" is incorrect
once one takes runtime configuration into account.

This includes:

 - Remove some obsolete information (e.g. we don't customize
   search engines anymore).
 - Group together related information.
 - Add information that could be useful to the Tor Browser team.

Thunderbird uses the hostname part of the sender's email address in the
Message-ID by default.

Since https://bugzilla.mozilla.org/show_bug.cgi?id=902580,
the timezone is not leaked in Message-ID anymore.

Design doc: update wrt. the loss of Torbirdy; better organize the whole Thunderbird section (refs: #17259)

For background, see #12689 and its various duplicates. The short version is:

 - Unfortunately, hkp://jirk5u4osbsr34t5.onion is way too unreliable.

 - Most non-tech-savvy OpenPGP users don't use keyservers at all,
   so this change should not affect them much.

 - Tech-savvy OpenPGP users who want to use the Web-of-Trust (which
   keys.openpgp.org's design essentially kills) should be able
   to switch to a keyserver of their choosing, that includes
   non-self certifications.

Let's use the Onion service instead of hkps://keys.openpgp.org/, so that we
don't lose end-to-end encryption and authentication of the keyserver in
Seahorse, which doesn't support hkps://. Alternatively, we could use
hkps://keys.openpgp.org/ everywhere else, but it feels simpler to use the same
keyserver everywhere.

At this point, the only Tails systems that are affected by this change are those
run without GnuPG persistence, and newly created persistent GnuPG configuration.
Pre-existing persistent GnuPG configuration is not updated (yet).

On the test suite front:

 - This commit keeps the Chutney-based redirector setup as-is, except it will
   proxy requests to keys.openpgp.org, instead of pool.sks-keyservers.net
   previously. This should work as long as keys.openpgp.org supports cleartext
   communication on port 11371.

 - In theory, our long-term plan is to replace this with a local mock keyserver
   Onion service. We'll see if that's still worth the effort once we redirect
   requests to a more reliable upstream keyserver.

 - I'm removing the @fragile tag for torified_gnupg.feature. There might
   be other reasons why these scenarios are fragile; let's learn about them.

I had documented this in our design doc in
March (179b3335). A few months later, sajolida
document this again elsewhere
(ac10f0a3)

Let's not maintain this info in two different places, especially given it is
clearly not obvious how one could/should find the second instance.

Replace all calls to config/chroot_local-includes/usr/local/sbin/tor-has-bootstrapped
with `/bin/systemctl --quiet is-active tails-tor-has-bootstrapped.target`.

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/

This is a follow-up on commit:7a1d01de, that
removed these patches.

This avoids the need to build and upload Thunderbird packages every now and
then. Instead, we'll need to refresh our patches when they don't apply
as-is anymore.

Current patchset imported from our icedove.git at
commit a3eab1e85558f2c9cf01d332920ac81fea3cd9fd.

commit:35bdf510 renamed this file.

This section is about both l10n and i18n.

All this is about l10n, not i18n.

… and not "point-release" nor "minor release".

The project was renamed, what, 8 years ago?

Shipping them in user.js has a few downsides:

 - They override whatever is in prefs.js so basically prefs in user.js are
   locked:  any modification done in about:config will be reverted next time Tor
   Browser starts, which can be a PITA when developing Tails.

 - In about:config, all these prefs are listed as modified by the user,
   which feels wrong.

 - It makes it harder for derivatives to implement things properly.

I can't manage to have them be taken into account. Presumably
this would be doable by adding them to omni.ja but let's not bother:
I see little downside to simplify things here.