Project

General

Profile

Bug #11419

Deal with mandatory extension signing post FF45esr

Added by anonym over 1 year ago. Updated 8 months ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
05/14/2016
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
feature/12464-tor-browser-7.0
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Browser

Description

See e.g.: https://support.mozilla.org/en-US/kb/add-on-signing-in-firefox

Basically, Firefox >45 will refuse to load extensions that are not signed. For Firefox 45 (which Tor Browser 6.0.x is based on) it can be disabled via the xpinstall.signatures.required pref, but the add-ons page will show semi-scary warning for such extensions.

This is a problem primarily for our amnesia branding extension, which we generate at build. Most likely we cannot use that approach any more, but instead we'll have to resort to modifying the Tor Browser installation directory (probably some omni.ja file or similar).


Related issues

Related to Tails - Bug #11994: TorBrowser : add-ons couldn't be verified Duplicate 11/24/2016
Blocks Tails - Feature #12115: Migrate to Tor Browser based on FF52 Resolved 02/18/2015

Associated revisions

Revision fdb22c3d (diff)
Added by anonym over 1 year ago

Disable the requirement of signatures for extensions.

At the moment AdBlock Plus and our amnesia branding extensions are not
signed and not loaded by the Tor Browser otherwise.

Refs: #11419

Revision 1a7c81d3 (diff)
Added by anonym 10 months ago

WIP: patch .js files to add exceptions for Tails' extensions.

According to gk [1] this approach should work, but it didn't for me.

[1] https://lists.torproject.org/pipermail/tbb-dev/2017-April/000517.html

Will-fix: #11419

Revision 415f520f (diff)
Added by anonym 9 months ago

Tor Browser: add signing exceptions for Tails' extensions.

... by patching the hack applied by the Tor Browser developers.

Will-fix: #11419

History

#1 Updated by intrigeri over 1 year ago

Two things:

  • I've been told that adding one's own key to the list of those trusted by Firefox for signing extensions is not so hard, and well documented. We do that for our APT repo, perhaps we can do the same for amnesia branding?
  • Disabling xpinstall.signatures.required is probably OK as a short-term workaround for 2.4, but on the slightly longer term I'd like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

#2 Updated by anonym over 1 year ago

intrigeri wrote:

Two things:

  • I've been told that adding one's own key to the list of those trusted by Firefox for signing extensions is not so hard, and well documented. We do that for our APT repo, perhaps we can do the same for amnesia branding?

Sure, but will this actually be possible since the key has to be available during build, for everyone? Well, we can generate the signing key during build and then let it disappear into the empty void, but it feels wrong.

  • Disabling xpinstall.signatures.required is probably OK as a short-term workaround for 2.4

Thanks, I feel more confident about #11403 with you "probably" backing me on this. :)

but on the slightly longer term I'd like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

Clearly I agree that we need a better solution, but inside Tails we do not really depend much on DAVE, right?

#3 Updated by intrigeri over 1 year ago

Sure, but will this actually be possible since the key has to be available during build, for everyone?

Well, that's not what I meant. We could do exactly the same as what we do for our custom Debian packages: build, sign and publish outside of the regular build process.

Well, we can generate the signing key during build and then let it disappear into the empty void, but it feels wrong.

Agreed.

but on the slightly longer term I'd like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

Clearly I agree that we need a better solution, but inside Tails we do not really depend much on DAVE, right?

Yes, we do: when they haven't enough room left for an incremental upgrade, users are pointed to a full ISO download, and that uses DAVE. Nothing tells them that they need to download the ISO from a non-Tails system.

#4 Updated by anonym over 1 year ago

intrigeri wrote:

Sure, but will this actually be possible since the key has to be available during build, for everyone?

Well, that's not what I meant. We could do exactly the same as what we do for our custom Debian packages: build, sign and publish outside of the regular build process.

I see. IMHO generating it during build is very nice, and I think I'd rather modify the langpacks (which do not need be signed) with the corresponding changes rather than introducing yet another .deb to maintain.

but on the slightly longer term I'd like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

Clearly I agree that we need a better solution, but inside Tails we do not really depend much on DAVE, right?

Yes, we do: when they haven't enough room left for an incremental upgrade, users are pointed to a full ISO download, and that uses DAVE. Nothing tells them that they need to download the ISO from a non-Tails system.

Got it, thanks!

#5 Updated by intrigeri over 1 year ago

I see. IMHO generating it during build is very nice, and I think I'd rather modify the langpacks (which do not need be signed) with the corresponding changes

Fine by me.

rather than introducing yet another .deb to maintain.

Just to clarify, I was not suggesting to introduce a .deb, but to build, sign and publish the add-on in XPI format.

#6 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_2.6 to Tails_2.9.1

#7 Updated by anonym about 1 year ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#8 Updated by anonym about 1 year ago

I think an easier way to support this is:

  • Replace AdBlock Plus with uBlock Origins (#9833)
  • Kill the amnesia branding plugin, and instead modify the langpacks. We do that any way, so why not some more? :)

#9 Updated by anonym about 1 year ago

  • Blocked by Feature #9833: Replace AdBlock Plus with uBlock Origin added

#10 Updated by anonym about 1 year ago

  • Target version changed from Tails 2.10 to Tails_2.11

The new ESR is out in March, and now that is Tails 2.11.

#11 Updated by anonym about 1 year ago

  • Blocked by deleted (Feature #9833: Replace AdBlock Plus with uBlock Origin)

#12 Updated by anonym about 1 year ago

anonym wrote:

I think an easier way to support this is:

  • Replace AdBlock Plus with uBlock Origins (#9833)

This wont help us apparently: installing uBlock Origins via the .deb still results in an unsigned add-on.

Worst case: we fetch the addon (AdBlock Plus or uBlock Origins) from AMO at build time. The extension signing should make this safe even if we just fetch over https.

  • Kill the amnesia branding plugin, and instead modify the langpacks. We do that any way, so why not some more? :)

This still works.

#13 Updated by sajolida about 1 year ago

  • Related to Bug #11994: TorBrowser : add-ons couldn't be verified added

#14 Updated by spriver about 1 year ago

Working on #9833 I did some tests with installing addons via apt (xul-ext-ublock-origin). My findings were:

  • After the installation it will be loaded as a signed addon in FF45-esr, FF50 and FF51 from /usr/share/xul-ext/ublock-origin
  • Once the addon will be linked via ln -s into a location in the browsers hidden folder in the home directory (e.g. ~/.mozilla/firefox/$profilename/extensions on a pure Debian, resp. ~/.tor-browser/profile-default/extensions for Tails) the signing will be broken
  • Loading a plugin for Tor Browser in Tails from a location that is not in ~/.tor-browser/profile.default/ is not possible. I suspect that this is a security mechanism of the TBB as deactivating AppArmor for TBB in Tails won't change it.

#15 Updated by anonym about 1 year ago

#16 Updated by anonym 11 months ago

  • Target version changed from Tails_2.11 to Tails_2.12

#17 Updated by intrigeri 10 months ago

  • Priority changed from Normal to Elevated

#18 Updated by anonym 10 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to feature/11419-deal-with-tor-browser-add-on-signing

The featyre branch doesn't work but should according to gk: https://lists.torproject.org/pipermail/tbb-dev/2017-April/000517.html

#19 Updated by anonym 9 months ago

  • Target version changed from Tails_2.12 to Tails_3.0~rc1

#20 Updated by anonym 9 months ago

  • % Done changed from 10 to 50
  • QA Check set to Ready for QA
  • Feature Branch changed from feature/11419-deal-with-tor-browser-add-on-signing to feature/12464-tor-browser-7.0
  • Type of work changed from Research to Code

It seems I just had a typo (or two) in my patches, resulting in syntax errors in the JavaScript. This works! :)

#21 Updated by anonym 8 months ago

  • Assignee changed from anonym to intrigeri

#22 Updated by intrigeri 8 months ago

Code review passes.

#23 Updated by intrigeri 8 months ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

#24 Updated by intrigeri 8 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF