Opened 4 years ago

Last modified 13 days ago

#10394 reopened task

Torbrowser's updater updates HTTPS-everywhere

Reported by: StrangeCharm Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, TorBrowserTeam201712
Cc: mcs, brade, Dbryrtfbcbhgf, yawning, tom, boklm, legind Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by gk)

Let's think about shipping HTTPS-Everywhere solely via our updater, disabling update pings for that extension as well.

Child Tickets

Change History (21)

comment:1 Changed 4 years ago by nickm

Component: - Select a componentTorBrowserButton

I think all this updater stuff is TBB. If not, please reassign.

comment:2 Changed 3 years ago by erinn

Component: TorBrowserButtonTor Browser
Keywords: tbb-torbutton added
Owner: changed from mikeperry to tbb-team

comment:3 Changed 16 months ago by bugzilla

Keywords: pantheon chronos tbb-torbutton removed
Resolution: worksforme
Severity: Normal
Status: newclosed

comment:4 Changed 16 months ago by gk

Resolution: worksforme
Status: closedreopened
Summary: Torbrowser's updater updates HTTPS-everwhereTorbrowser's updater updates HTTPS-everywhere

We are still getting HTTPS-E updates outside of our updater.

comment:5 in reply to:  4 Changed 16 months ago by mcs

Replying to gk:

We are still getting HTTPS-E updates outside of our updater.

When we ship a new version of HTTPS-E with a new release of Tor Browser, we arrange for it to be "force updated" (files replaced) so that the user is left with a known version of HTTPS-E which has been tested with TB. Interim updates are still retrieved from addons.mozilla.org using the extension update mechanism so users can get updates if desired. We use the same approach for NoScript.

Do we want to do something different? If not, then this bug can be closed.

comment:6 Changed 16 months ago by gk

Description: modified (diff)
Keywords: tbb-security added
Milestone: Chronos: phase two
Type: projecttask

I think we want to have a ticket about shipping HTTPS-E solely via our updater, disabling update pings to EFF. I thought there was already a ticket for this but I did not found one and thought this one might fit.

comment:7 Changed 16 months ago by bugzilla

mcs, thanks for the clarification. But,

Interim updates are still retrieved from addons.mozilla.org using the extension update mechanism

No. From EFF.

so users can get updates if desired.

What does it mean (desired)? Update Add-ons Automatically is selected by default.

We use the same approach for NoScript.

No. But, maybe, it's better to use the same, because recent updates led to 5.2.0 on alpha, 5.1.x on stable and 5.2.1 on AMO.

comment:8 in reply to:  7 ; Changed 16 months ago by mcs

Replying to bugzilla:

mcs, thanks for the clarification. But,

Interim updates are still retrieved from addons.mozilla.org using the extension update mechanism

No. From EFF.

Thanks. My mistake.

so users can get updates if desired.

What does it mean (desired)? Update Add-ons Automatically is selected by default.

It means users do have a way to disable updates if they want to do so. But most will keep the default setting.

We use the same approach for NoScript.

No. But, maybe, it's better to use the same, because recent updates led to 5.2.0 on alpha, 5.1.x on stable and 5.2.1 on AMO.

There is a policy question here: should we disable updates for bundled extensions. By allowing updates from EFF or AMO, we risk that users may get a version of an extension that is somehow incompatible with Tor Browser. But by allowing updates we ensure that users will have the latest (and hopefully most secure) versions of HTTPS-E and NoScript.

comment:9 in reply to:  6 Changed 16 months ago by bugzilla

Replying to gk:

we want to have a ticket about shipping HTTPS-E solely via our updater

Maybe, you mean your update servers instead of AMO, or you'll have to make a new release of TBB for every update.

comment:10 Changed 11 months ago by gk

Cc: Dbryrtfbcbhgf added

#21260 is a duplicate.

comment:11 Changed 11 months ago by yawning

Cc: yawning added

comment:12 in reply to:  11 Changed 11 months ago by Dbryrtfbcbhgf

posted on wrong bug report. please delete

Last edited 11 months ago by Dbryrtfbcbhgf (previous) (diff)

comment:13 Changed 5 months ago by tom

Cc: tom added

comment:14 in reply to:  8 Changed 4 months ago by yawning

Replying to mcs:

There is a policy question here: should we disable updates for bundled extensions.

Yes.

By allowing updates from EFF or AMO, we risk that users may get a version of an extension that is somehow incompatible with Tor Browser.

#23258, #22974

comment:15 Changed 2 months ago by cypherpunks

+1, as #23772.

comment:16 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201711 added
Status: reopenedassigned

I heard we are close to be able to test that. Hopefully this can already happen in the next regular alpha release. Putting it on our radar for November.

comment:17 Changed 6 weeks ago by gk

Cc: boklm added
Keywords: TorBrowserTeam201711R added; TorBrowserTeam201711 removed
Status: assignedneeds_review

bug_10394_v2 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_10394_v2&id=50982eda6d3687aa5bcc2d088546f82c4fa7e53d) in my tor-browser-build repository has a fix for this bug. Note: this breaks at the time of writing the nightly builds. Given that we need to get alphas out rather soon, that's okay for now. The potential breakage will be addressed in #24179.

comment:18 Changed 6 weeks ago by boklm

Resolution: fixed
Status: needs_reviewclosed

This looks good to me. I applied it to master as commit 50982eda6d3687aa5bcc2d088546f82c4fa7e53d.

comment:19 Changed 5 weeks ago by gk

Cc: legind added
Keywords: TorBrowserTeam201711 added; TorBrowserTeam201711R removed
Resolution: fixed
Status: closedreopened

Firefox does not like our trick in a WebExtensions context:

1510514437300	addons.webextension.<unknown>	ERROR	Loading extension 'null': Reading manifest: Error processing applications.gecko.update_url: Error: Access denied for URL data:text/plain,
1510514437500	addons.xpi-utils	WARN	updateMetadata: Add-on https-everywhere-eff@eff.org is invalid: Error: Extension is invalid (resource://gre/modules/addons/XPIProvider.jsm:963:11) JS Stack trace: loadManifestFromWebManifest<@XPIProvider.jsm:963:11 < TaskImpl_run@Task.jsm:319:42 < Handler.prototype.process@Promise-backend.js:932:23 < this.PromiseWalker.walkerLoop@Promise-backend.js:813:7 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:747:11 < syncLoadManifestFromFile@XPIProvider.jsm:1621:5 < updateMetadata@XPIProviderUtils.js:1785:21 < processFileChanges@XPIProviderUtils.js:2009:26 < this.XPIProvider.checkForChanges@XPIProvider.jsm:3899:34 < this.XPIProvider.startup@XPIProvider.jsm:2839:25 < callProvider@AddonManager.jsm:242:12 < _startProvider@AddonManager.jsm:795:5 < AddonManagerInternal.startup@AddonManager.jsm:1005:9 < this.AddonManagerPrivate.startup@AddonManager.jsm:3062:5 < amManager.prototype.observe@addonManager.js:65:9

So, we need something better and need to rebuild the alphas.

comment:20 Changed 13 days ago by gk

Moving tickets to December 2017

comment:21 Changed 13 days ago by gk

Keywords: TorBrowserTeam201712 added; TorBrowserTeam201711 removed

Moving tickets to December 2017, for realz.

Note: See TracTickets for help on using tickets.