Torbrowser's updater updates HTTPS-everywhere
Let's think about shipping HTTPS-Everywhere solely via our updater, disabling update pings for that extension as well.
Activity
added TorBrowserTeam202006R in Legacy / Trac component::applications/tor browser in Legacy / Trac https-everywhere in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac reviewer::gk in Legacy / Trac severity::normal in Legacy / Trac status::needs-review in Legacy / Trac tbb-security in Legacy / Trac type::task in Legacy / Trac labels
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.
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.
Trac:
Description: N/Ato
Let's think about shipping HTTPS-Everywhere solely via our updater, disabling update pings for that extension as well.
Milestone: Chronos: phase two to N/A
Type: project to task
Keywords: N/A deleted, tbb-security addedmcs, 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.
-
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.
-
legacy/trac#21260 (moved) is a duplicate.
Trac:
Cc: mcs, brade to mcs, brade, Dbryrtfbcbhgf 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.
+1, as legacy/trac#23772 (moved).
-
bug_10394_v2(https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_10394_v2&id=50982eda6d3687aa5bcc2d088546f82c4fa7e53d) in mytor-browser-buildrepository 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 legacy/trac#24179 (moved).Trac:
Cc: mcs, brade, Dbryrtfbcbhgf, yawning, tom to mcs, brade, Dbryrtfbcbhgf, yawning, tom, boklm
Status: assigned to needs_review
Keywords: TorBrowserTeam201711 deleted, TorBrowserTeam201711R added -
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 (re[/gre/modules/addons/XPIProvider.jsm:963:11)](/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:9So, we need something better and need to rebuild the alphas.
Trac:
Status: closed to reopened
Keywords: TorBrowserTeam201711R deleted, TorBrowserTeam201711 added
Resolution: fixed to N/A
Cc: mcs, brade, Dbryrtfbcbhgf, yawning, tom, boklm to mcs, brade, Dbryrtfbcbhgf, yawning, tom, boklm, legind Hainish says it should hopefully be ready for the 2018.3.27 release:
I plan on making this the release that incorporates the
sign-rulesetsbranch.Ruleset updates are finally here!
Today HTTPS Everywhere requested permission to update itself in TB 8.0a10 https://share.riseup.net/#Caex1xF8eY8YSUOksRdKkg
Yeah that's legacy/trac#27277 (moved)
-
Hm. We had this before but ran into scary tor warnings, see: legacy/trac#16427 (moved) and legacy/trac#13129 (moved). 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.
-
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. -
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. Starting the browser with
./start-tor-browser --verboseI 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.jsonfile in HTTPS Everywhere. Though for both, I see it only on the first time I clickCheck 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?
Trac:
Username: rustybird-
Here's a small patch.
I tested it on top of TB 9.0.10 (rezipped omni.ja), with
extensions.update.intervalset to60seconds, by watching requests viaSETEVENTS STREAMon a tor control port: The eff.org version check ping is gone. It's even more obvious if the NoScript ID is added to the patch as well, then there's no update traffic at all.Trac:
Username: rustybird -
Replying to rustybird:
Here's a small patch.
I tested it on top of TB 9.0.10 (rezipped omni.ja), with
extensions.update.intervalset to60seconds, by watching requests viaSETEVENTS STREAMon a tor control port: The eff.org version check ping is gone. It's even more obvious if the NoScript ID is added to the patch as well, then there's no update traffic at all.The permission path is an interesting idea. I had some hope we could get this ticket fixed without carrying yet another patch for it with us but I like the UX changes etc. we basically get for free with it. Plus no changes needed to the extension whatsoever and no weird console error messages either.
Maybe we could include this patch as part of our "don't block our unsigned extensions" patch where HTTPS-Everywhere is the only extension left anyway. Would be easy to make this to an "treat https-e special" patch.
rustybird: have you checked whether the ruleset updates are unaffected by your patch (because those are updates we want to keep getting)?
Trac:
Status: needs_review to needs_information -
Replying to gk:
Maybe we could include this patch as part of our "don't block our unsigned extensions" patch where HTTPS-Everywhere is the only extension left anyway. Would be easy to make this to an "treat https-e special" patch.
If the plan still is to eventually disable NoScript updates too, then it might be simpler to keep the patch separate and later add a fixup checking for the NoScript ID as well. Just a thought.
rustybird: have you checked whether the ruleset updates are unaffected by your patch
Yes, they still work: There are connections to
www.https-rulesets.org:443andsecuredrop.org:443. And when I start with an old HTTPS Everywhere version that includes an outdated ruleset, therulesets-timestampfields inbrowser-extension-data/https-everywhere-eff@eff.org/storage.jsshow that those updates are applied.Trac:
Username: rustybird -
Replying to rustybird:
Replying to gk:
Maybe we could include this patch as part of our "don't block our unsigned extensions" patch where HTTPS-Everywhere is the only extension left anyway. Would be easy to make this to an "treat https-e special" patch.
If the plan still is to eventually disable NoScript updates too, then it might be simpler to keep the patch separate and later add a fixup checking for the NoScript ID as well. Just a thought.
Yes, that's still the plan. I am not overly worried about NoScript having any impact here. Once we disable updates for NoScript we want to make a signature check exception for it, too, because we don't want to be affected again by Mozilla messing up their signing certificate renewal. So, this would fit into a single patch together with HTTPS-Everywhere being exempted and its updates disabled.
What I am worried about is the additional review cost this move would imply because I think we should neither disable HTTPS-Everywhere's nor NoScript's update mechanism if we can't manage to track their releases and check whether those contain any new security issues or fixes for older ones.
rustybird: have you checked whether the ruleset updates are unaffected by your patch
Yes, they still work: There are connections to
www.https-rulesets.org:443andsecuredrop.org:443. And when I start with an old HTTPS Everywhere version that includes an outdated ruleset, therulesets-timestampfields inbrowser-extension-data/https-everywhere-eff@eff.org/storage.jsshow that those updates are applied.Great, thanks.
Trac:
Cc: mcs, brade, Dbryrtfbcbhgf, yawning, tom, boklm, legind to mcs, brade, Dbryrtfbcbhgf, tom, boklm, legind
Status: needs_information to needs_review -
Replying to gk:
Once we disable updates for NoScript we want to make a signature check exception for it, too, because we don't want to be affected again by Mozilla messing up their signing certificate renewal. So, this would fit into a single patch together with HTTPS-Everywhere being exempted and its updates disabled.
Ah, makes sense. Squash away!
What I am worried about is the additional review cost this move would imply because I think we should neither disable HTTPS-Everywhere's nor NoScript's update mechanism if we can't manage to track their releases and check whether those contain any new security issues or fixes for older ones.
For new security issues, the status quo could be preserved by making the TB build system default to shipping not necessarily the very latest extension release, but the latest on AMO. This would transform AMO from an authority that can unilaterally approve updates, to just an additional code reviewer (who can be overridden).
For old security issues, the status quo with
extensions.update.interval == 86400is 24h worst case, so 12h on average until an approved update is applied; which comes after however much time AMO approval takes... Hmm, how fast could the TB release process actually upload an update, assuming it's only an extension version bump and nothing else?Trac:
Username: rustybird
