Deal with the fact that Tor Browser won't ship language packs anymore
The major reason for this change are:
- Language packs are extensions and would need to be signed once Tor Browser starts requiring all extensions to be signed (see https://trac.torproject.org/projects/tor/ticket/26843, tracked as Feature #12571 here); Tor Browser modifies the strings so they can’t just take the langpacks signed by Mozilla.
- multi-lingual TBA (https://trac.torproject.org/projects/tor/ticket/26843)
When building a Tails image, we extract langpacks from the full set of localized Tor Browser tarballs (
config/chroot_local-hooks/10-tbb). So once there’s no langpack in there, we don’t know how to ship translations for Tor Browser anymore.
This work upstream is targetted at Tor Browser 9.0 == Firefox 68esr = Oct 2019. As Georg wrote, it “will be 9.0 material if at all”.
#9 Updated by intrigeri 2019-02-08 16:50:53
My understanding is that the Tor Browser build system, as of tbb-8.0.5-build2, downloads signed langpacks from Mozilla, then for each of them, replaces the default bookmarks and search plugins with custom ones, and repacks it.
And on our side, we extract the langpacks (
.xpi) from Tor Browser tarballs and copy them as-is into
So, we could download the langpacks from Mozilla, customize the bookmarks and search plugins ourselves (by copying those from the en-US Tor Browser tarball), and disable signature verification for these XPIs. This approach has a number of problems:
- Given https://ftp.mozilla.org/pub/firefox/candidates/ does not support plaintext HTTP, we need to mirror the langpacks under a plaintext HTTP URL (similarly to our Tor Browser archive), so that apt-cacher-ng can cache it, and then we need to add a verification mechanism. That’s errorprone to code and repetitive busywork every time we upgrade Tor Browser. OTOH we can stop mirroring all the Tor Browser tarballs: we only need the en-US one.
- It requires either Feature #12571 being fixed nicely, or us carrying more custom code to disable extension signature verification.
#10 Updated by intrigeri 2019-02-08 17:06:38
Also, for our chrooted browsers (currently: Unsafe Browser), we modify each langpack again in
delete_chroot_browser_searchplugins(). That’s one more thing that won’t survive extension signing unless Feature #12571 is fixed nicely, or we carry more custom code to disable extension signature verification.
#11 Updated by intrigeri 2019-02-08 18:01:04
On https://trac.torproject.org/projects/tor/ticket/27466#comment:18 I’ve argued in favour of postponing this change. Who knows, maybe the Tor Browser folks will prefer to give us a workaround we can use so they can release this change in their 8.5 :)
I’ll keep handling the communication with upstream for now but I’d rather not be responsible for the implementation.
#13 Updated by intrigeri 2019-02-08 19:49:37
- Target version changed from Tails_3.13 to Tails_3.14
- Parent task deleted (
) Feature #16337
Won’t happen in TB 8.5, now targets 9.0 ⇒ /me relaxes. Still, I’ll keep this on my radar to ensure I handle the communication with upstream part the best I can (it’s not exactly anonym’s cup of tea last time I checked, but if you want to sneak out of your comfort zone a bit, this could be a good one :)
#20 Updated by intrigeri 2020-05-12 13:03:19
- Priority changed from Elevated to Normal
> After a meeting with the Tor Browser devs we have learned: “This will not happen anytime soon.”
Thank you for gathering this info and reporting back.
That’s not urgent anymore so I’m downgrading priority accordingly :)