Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#15689 closed enhancement (fixed)

Switch back to using the HTTPS-Everywhere git repository for Tor Browser builds

Reported by: gk Owned by: gk
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-gitian, tbb-4.5-alpha, TorBrowserTeam201504R
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

#11630 is fixed in HTTPS-Everywhere 5.x which should allow us to switch back to using signed git tags for the HTTPS-Everywhere extension we ship in Tor Browser.

Child Tickets

Change History (11)

comment:1 Changed 6 years ago by gk

Keywords: tbb-4.5-alpha added

Let's try to get that going in 4.5 as this release won't be a security update. If indeed something is still going wrong it is not so critical to rebuild the bundles yet another time.

comment:2 Changed 6 years ago by gk

Status: newneeds_review

bug_15689_v2 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/log/?h=bug_15689_v2) has the fix. I tested in an LXC and a KVM environment on different machines and the builds are still matching. Should be working now.

comment:3 Changed 6 years ago by gk

Keywords: TorBrowserTeam201504R added

comment:4 Changed 6 years ago by mcs

Status: needs_reviewneeds_revision

Kathy and I reviewed these changes. They look OK, except we think you missed un-commenting the final "cd .." within the HTTPS-Everywhere build commands in gitian/descriptors/mac/gitian-bundle.yml (the last line below):

@@ -103,12 +104,12 @@ script: |
   ~/build/dzip.sh ../../../$TORBROWSER_NAME.app/TorBrowser/Data/Browser/profile.default/extensions/torbutton@torproject.org.xpi .
   cd ../../../
   #
-  # cd https-everywhere
+  cd https-everywhere
   # XXX: Bloody hack to workaround a bug in HTTPS_E's git hash extraction in
   # makexpi.sh. See https://trac.torproject.org/projects/tor/ticket/10066
-  # rm -f .git/refs/heads/master
-  # ./makexpi.sh
-  # cp pkg/*.xpi ../$TORBROWSER_NAME.app/TorBrowser/Data/Browser/profile.default/extensions/https-everywhere@eff.org.xpi
+  rm -f .git/refs/heads/master
+  ./makexpi.sh
+  cp pkg/*.xpi ../$TORBROWSER_NAME.app/TorBrowser/Data/Browser/profile.default/extensions/https-everywhere@eff.org.xpi
   # cd ..

comment:5 Changed 6 years ago by gk

Status: needs_revisionneeds_review

D'oh! I should have waited until my Mac build had finished es well. This is fixed in bug_15689_v3 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/log/?h=bug_15689_v3).

comment:6 Changed 6 years ago by mcs

Looks good.

comment:7 Changed 6 years ago by mikeperry

One thing that gives me pause here is that the HTTPS-Everywhere team recently decided to start distributing their addon from addons.mozilla.org (in addition to eff.org). This could very well mean that when you build from source, you no longer are pointing at the eff.org update URL and eff's offline signing key. We should verify this, and/or postpone past 4.5-stable to give us more time to check with them about what their policy will be going forward about the update URL and their build scripts.

comment:8 Changed 6 years ago by mikeperry

Perhaps simpler to check: Do our builds match their official eff.org releases (or at least their xpi contents) byte-for-byte?

comment:9 in reply to:  8 Changed 6 years ago by gk

Replying to mikeperry:

Perhaps simpler to check: Do our builds match their official eff.org releases (or at least their xpi contents) byte-for-byte?

Only the rules.sqlite file is different which is not surprising given #11630.

Last edited 6 years ago by gk (previous) (diff)

comment:10 Changed 6 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

Merged in commit b1a683d04ffd9054e2807013c5bc35fed8604b20.

comment:11 Changed 6 years ago by gk

FWIW: I pushed a fixup in commit c5e0b0b7517e5e1e2dfe23506db2d9b7b0939ef1 to get rid of the AMO version, which gets built since 5.0.2 as well, as we don't need it.

Note: See TracTickets for help on using tickets.