Project

General

Profile

Feature #12571

Find a nicer way to add exceptions from mandatory signing for our Tor Browser add-ons

Added by anonym about 2 years ago. Updated about 2 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/19/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Browser

Description

The current approach is 415f520fde6f84c5f32ff3769f16f42c8209137d, where we unpack and patch the relevant files in the omni.ja archives. We should upstream this to Tor Browser somehow so we don't have to carry this delta.

A discussion about this has slowly been started a while back here: https://lists.torproject.org/pipermail/tbb-dev/2017-April/000515.html

It would be good to fix this before Tor Browser drops their current hack and signs their extensions: https://trac.torproject.org/projects/tor/ticket/26553. Otherwise we'll have to make our hack even worse: instead of "merely" adding an add-on to the whitelist we would have to carry the entire whitelist code as part of our delta.

Regarding timing, Georg told us it "will be 9.0 material if at all". Tor Browser 9.0 Firefox 68 Oct 2019.


Related issues

Related to Tails - Feature #15023: Upgrade to Tor Browser based on Firefox ESR60 Resolved 08/30/2017 08/09/2018
Related to Tails - Bug #16048: Deal with the fact that Tor Browser won't ship language packs anymore Confirmed 10/12/2018
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed 03/22/2019

History

#1 Updated by anonym almost 2 years ago

  • Target version changed from Tails_3.0 to Tails_3.1

#2 Updated by u almost 2 years ago

Upstream Tor bug which plans to add this to their design documentation: https://trac.torproject.org/projects/tor/ticket/21922

#3 Updated by u almost 2 years ago

Upstream Tor bug about unreproducible omni.ja: https://trac.torproject.org/projects/tor/ticket/21960

#4 Updated by intrigeri almost 2 years ago

#5 Updated by anonym almost 2 years ago

  • Target version changed from Tails_3.1 to Tails_3.2

#6 Updated by intrigeri over 1 year ago

u wrote:

Upstream Tor bug about unreproducible omni.ja: https://trac.torproject.org/projects/tor/ticket/21960

(Just to save anonym some time: this seems unrelated to this ticket.)

#7 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.2 to Tails_3.3
  • Type of work changed from Communicate to Code

anonym wrote:

A discussion about this has slowly been started a while back here: https://lists.torproject.org/pipermail/tbb-dev/2017-April/000515.html

My understanding is that an agreement was reached (add a pref with the whitelist), so next step is to actually implement it. I'll let you evaluate if this is something you can do yourself, or something we should kindly ask Tor Browser developers (or other nice people we know who might want to help, Cc garrettr) to implement it themselves.

I suggest you spend a couple hours (not more!) on this evaluation during the 3.3 cycle and then adjust the timeline depending on the outcome.

#8 Updated by intrigeri over 1 year ago

#9 Updated by intrigeri over 1 year ago

#10 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.3 to Tails_3.5

#11 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.5 to Tails_3.6

#12 Updated by intrigeri over 1 year ago

#13 Updated by intrigeri over 1 year ago

#14 Updated by anonym over 1 year ago

So I has paid with a few hours of my life due to this hack with 55766776a514b2379d37e2f002a99b5c85cbeeb4. At the time I didn't get why this fixed it, but here's an explanation from segfault (thanks! ❤):

the files in omni.js don't have $tbb_timestamp, but January 19 2018. This means they are newer than the two files you want to compress, which causes the update to fail. If I use "7z u -ux2 -mtc=off -tzip" instead, the update works. I would recommend using -ux2y2w2 to prevent this error in the future (see https://www.scottklement.com/p7zip/MANUAL/switches/update.htm for an explanation of these cryptic values).

#15 Updated by anonym over 1 year ago

  • Target version changed from Tails_3.6 to Tails_3.7

The earliest I'll look at this again is during (if attending) or after Tor Dev @ Rome, March 2018.

#16 Updated by intrigeri over 1 year ago

Target version changed from Tails_3.6 to Tails_3.7

The earliest I'll look at this again is during (if attending) or after Tor Dev @ Rome, March 2018.

… that is before the 3.6 release.

#17 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.7 to Tails_3.6

(Increasing the chances you discuss this in person with the Tor Browser team in Rome.)

#18 Updated by bertagaz about 1 year ago

  • Target version changed from Tails_3.6 to Tails_3.7

#19 Updated by anonym about 1 year ago

Let's see what the Tor browser folks will do for their own extensions when porting to FF60. I should attend any meeting/ticket discussion about this and make sure what they pick works for us.

#20 Updated by intrigeri about 1 year ago

#21 Updated by intrigeri about 1 year ago

#22 Updated by intrigeri about 1 year ago

anonym will email tbb-dev@ during this cycle and once 3.7 is released we'll re-evaluate and see if this work needs to be shared/assigned differently.

#23 Updated by bertagaz about 1 year ago

  • Target version changed from Tails_3.7 to Tails_3.8

#24 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_3.8 to Tails_3.9

Let's handle this as part of the migration to ESR60.

#25 Updated by intrigeri about 1 year ago

  • Related to Feature #15023: Upgrade to Tor Browser based on Firefox ESR60 added

#26 Updated by intrigeri 11 months ago

  • Assignee changed from anonym to intrigeri

We'll decide on #15531 how we'll handle this.

#27 Updated by intrigeri 11 months ago

#28 Updated by intrigeri 11 months ago

#29 Updated by intrigeri 11 months ago

  • Assignee deleted (intrigeri)
  • Target version deleted (Tails_3.9)

One year later, this (arguably ugly) hack has not caused us any major trouble. I was concerned we would need to update it for Firefox ESR60 but works just fine there. So the only reasons I see in favour of keeping this ticket open are:

  • Adding a Tor Browser pref for that list of extensions increases the chances that the Tor Browser team notices if they ever break it, e.g. if they start signing their own extensions and don't need the pref anymore, but that's quite hypothetical.
  • It's less stressful to deal with this as a new feature, with a relaxed timeline, than in a hurry, to fix stuff after the fact, whenever our current hack breaks.

So for now I'm dropping the target version but I'm refraining from rejecting this ticket. If someone feels strongly either way, let's talk.

#30 Updated by intrigeri 11 months ago

#31 Updated by intrigeri 10 months ago

  • Description updated (diff)

#32 Updated by intrigeri 8 months ago

  • Target version set to Tails_3.13

According to the latest Tor Browser team roadmap, https://trac.torproject.org/projects/tor/ticket/26553 should happen in Tor Browser 8.5, scheduled for March 2019.

#33 Updated by intrigeri 8 months ago

#34 Updated by intrigeri 8 months ago

  • Parent task set to #16047

#35 Updated by anonym 5 months ago

  • Parent task changed from #16047 to #16337

#36 Updated by intrigeri 4 months ago

  • Related to Bug #16048: Deal with the fact that Tor Browser won't ship language packs anymore added

#37 Updated by intrigeri 4 months ago

This is for 3.14 (see email from geko on tails-dev) but I think we should work on this ASAP and not wait for post-3.13.

#38 Updated by intrigeri 4 months ago

  • Description updated (diff)
  • Target version changed from Tails_3.13 to Tails_3.14

#39 Updated by intrigeri 4 months ago

  • Parent task deleted (#16337)

#40 Updated by intrigeri 4 months ago

#41 Updated by intrigeri 4 months ago

#42 Updated by intrigeri about 2 months ago

  • Target version deleted (Tails_3.14)

Also available in: Atom PDF