Opened 5 years ago

Last modified 3 weeks 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, TorBrowserTeam201805, https-everywhere
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 (38)

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 4 years ago by erinn

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

comment:3 Changed 2 years ago by bugzilla

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

comment:4 Changed 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 2 years 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 21 months ago by gk

Cc: Dbryrtfbcbhgf added

#21260 is a duplicate.

comment:11 Changed 21 months ago by yawning

Cc: yawning added

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

posted on wrong bug report. please delete

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

comment:13 Changed 15 months ago by tom

Cc: tom added

comment:14 in reply to:  8 Changed 14 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 12 months ago by cypherpunks

+1, as #23772.

comment:16 Changed 12 months 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 11 months 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 11 months ago by boklm

Resolution: fixed
Status: needs_reviewclosed

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

comment:19 Changed 11 months 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 10 months ago by gk

Moving tickets to December 2017

comment:21 Changed 10 months ago by gk

Keywords: TorBrowserTeam201712 added; TorBrowserTeam201711 removed

Moving tickets to December 2017, for realz.

comment:22 Changed 9 months ago by gk

Keywords: TorBrowserTeam201801 added; TorBrowserTeam201712 removed

Moving tickets to 2018.

comment:23 Changed 8 months ago by gk

Keywords: TorBrowserTeam201802 added; TorBrowserTeam201801 removed

Moving tickets to Feb

comment:24 Changed 7 months ago by gk

Keywords: TorBrowserTeam201803 added; TorBrowserTeam201802 removed

Adding to our March plate.

comment:25 Changed 7 months ago by cypherpunks

Hainish says it should hopefully be ready for the 2018.3.27 release:

I plan on making this the release that incorporates the sign-rulesets branch.

https://github.com/EFForg/https-everywhere/issues/14907

comment:27 Changed 6 months ago by gk

Keywords: TorBrowserTeam201804 added; TorBrowserTeam201803 removed

Moving our tickets to April.

comment:28 Changed 5 months ago by gk

Keywords: TorBrowserTeam201805 added; TorBrowserTeam201804 removed

Moving remaining tickets to May.

comment:29 Changed 2 months ago by traumschule

Keywords: https-everywhere added

comment:30 Changed 8 weeks ago by traumschule

Today HTTPS Everywhere requested permission to update itself in TB 8.0a10
https://share.riseup.net/#Caex1xF8eY8YSUOksRdKkg

comment:31 Changed 8 weeks ago by cypherpunks3

Yeah that's #27277

comment:32 Changed 6 weeks ago by legind

gk, do you see any problem with simply setting the extension update URL to https://0.0.0.0/ rather than data:text/plain,? This doesn't result an the extension load-time error.

comment:33 Changed 6 weeks ago by gk

Hm. We had this before but ran into scary tor warnings, see: #16427 and #13129. We could check, though, whether they still occur. If not, great, let's do it. But if so, we should think harder about what to do.

comment:34 Changed 5 weeks ago by legind

I'm not seeing these warnings in the browser console when testing on the latest TB, but perhaps I'm missing something?

comment:35 in reply to:  34 Changed 5 weeks ago by gk

Replying to legind:

I'm not seeing these warnings in the browser console when testing on the latest TB, but perhaps I'm missing something?

Interesting. Do you get those messages if you use a Torbutton .xpi with the update URL changed to https://0.0.0.0/? One difference could be that this was only problematic for XPCOM extensions but is not an issue anymore for WebExtensions. If that's the case, great! Then let's switch to the HTTPS URL.

comment:36 Changed 5 weeks ago by legind

I don't see these warnings when modifying the Tor Button .xpi. Maybe they removed this as a warning at some point. To be clear, I'm just looking in the browser console - should I be looking elsewhere as well?

comment:37 in reply to:  36 Changed 5 weeks ago by gk

Replying to legind:

I don't see these warnings when modifying the Tor Button .xpi. Maybe they removed this as a warning at some point. To be clear, I'm just looking in the browser console - should I be looking elsewhere as well?

[09-12 07:23:47] Torbutton INFO: tor SOCKS: https://0.0.0.0/ via
                       --unknown--:6151cba48e49acf249f6b48fb13ce789
Sep 12 07:23:47.000 [warn] Rejecting SOCKS request for anonymous connection to private address [scrubbed].

is what I get in my terminal. I see the Tor warning in my browser console as well if I open about:addons, click on Extensions -> Torbutton (More button) -> right click -> Find Updates.

comment:38 Changed 3 weeks ago by legind

Starting the browser with

./start-tor-browser --verbose

I can now see

Sep 28 02:48:58.000 [warn] Rejecting SOCKS request for anonymous connection to private address [scrubbed].

But I don't see that first line.

I'm also seeing this when I update the manifest.json file in HTTPS Everywhere. Though for both, I see it only on the first time I click Check for Updates, not each subsequent time. Maybe this is due to addon update connection throttling?

Is the presence of these warnings really a blocker on moving forward here?

Last edited 3 weeks ago by legind (previous) (diff)
Note: See TracTickets for help on using tickets.