#26050 closed defect (fixed)

achieve update "watershed" for ESR60-based Tor Browser

Reported by: mcs Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr, TorBrowserTeam201809
Cc: boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Once Tor Browser is based on the ESR60 code, because of the switch to xz compression and SHA384-based signing for the MAR files, we will need to have an update "watershed" event. The purpose of this ticket is to track the things we need to do to make the watershed happen.

Let's suppose that for our stable channel the first release that uses the new MAR format is 8.0. This means:

  • When an older version of Tor Browser (< 8.0) requests an update, it must receive an old format MAR file that will update it to 8.0. We must keep these MAR files around as long as we care about updating older browsers (probably a long time).
  • Newer versions of Tor Browser (>= 8.0) must receive new format MAR files (of course).

Of course we will need to do this sooner for our alpha channel.

My guess is that it will make things easier if we use a new location for the new update requests, e.g., from https://aus1.torproject.org/torbrowser/update_4.

One useful thing to know is that setting MAR_OLD_FORMAT=1 in the environment before running the make_full_update.sh or make_incremental_update.sh script causes the old bzip2 compression to be used when creating the MAR file.

Child Tickets

#26234closedtbb-teamAdd support in update_responses for redirecting old versions to a separate directoryApplications/Tor Browser
#26362closedtbb-teamUse old MAR format when generating the MAR files for the first esr60-based alphaApplications/Tor Browser
#26363closedtbb-teamDon't use old mar-tools after the watershed for generating 64bit Tor Browser MAR files for WindowsApplications/Tor Browser
#26410closedtbb-teamStop using old MAR format in the second esr60-based alphaApplications/Tor Browser
#26411closedtbb-teamStop using old MAR format in the second esr60-based stable releaseApplications/Tor Browser
#26569closedtbb-teamRedirect pre-8.0a9 alpha users to a separate update directoryApplications/Tor Browser
#26570closedtbb-teamRedirect pre-8.0 stable users to a separate update directoryApplications/Tor Browser
#27178closedtbb-teamGenerating of incremental MAR files fails due to new compression formatApplications/Tor Browser
#27179closedtbb-teamAdapt patch written in bug 27178 (different compression algorithms) for update from 8.0a10 to next alpha releaseApplications/Tor Browser
#27182closedtbb-teamUpdate mar_compression for 8.0.1 releaseApplications/Tor Browser
#27183closedtbb-teamUpdate mar_compression for 8.0.2 releaseApplications/Tor Browser

Change History (10)

comment:1 Changed 19 months ago by cypherpunks

Not sure why I should write the obvious things, but:
switch users of alpha channel to beta channel,
switch users of release channel to esr channel.

comment:2 Changed 19 months ago by gk

Keywords: TorBrowserTeam201805 added
Priority: MediumVery High

comment:3 Changed 19 months ago by gk

Cc: boklm added
Status: newneeds_information

boklm: What are the things that come to mind server-side that need to get done? Update some redirects? And...? Or is it just creating and update_4 dir and that's it?

comment:4 Changed 19 months ago by boklm

Status: needs_informationnew

If we switch from update_3 to update_4, I think the list of things we should do before the 8.0 release are:

  • adding a symlink update_4/release -> update_3/release, so that update_4 URLs start working.
  • tell external tools such as torbrowser-launcher or gettor to switch to update_4 URLs

And then when releasing 8.0.1:

  • remove the update_4/release -> update_3/release symlink, put the 8.0.1 release in update_4/release and keep 8.0 in update_3/release.
  • add a redirect update_3/downloads.json -> update_4/downloads.json
  • add a redirect update_3/release/Linux_x86_64-gcc3/x/en-US -> update_4/release/Linux_x86_64-gcc3/x/en-US (which is the URL used by torbrowser-launcher)

As an alternative, maybe we can avoid an update_3 -> update_4 change, and instead redirect the update pings where the version number starts with 7. to a different directory updating users to 8.0. In that case the list of things to do before releasing version 8.0.1 would be:

  • teach the update_responses script to add redirects for 7.* versions in the .htaccess file to a different directory, for instance update_pre_8.0.

And when releasing 8.0.1:

  • copy update_3/release (containing the 8.0 update) to update_pre_8.0/release, and then update update_3/release normally.

So unless I'm missing something, it seems staying with update_3 and redirecting old versions to a different directory would be more simple than switching from update_3 to update_4.

comment:5 in reply to:  4 Changed 19 months ago by boklm

Replying to boklm:

  • teach the update_responses script to add redirects for 7.* versions in the .htaccess file to a different directory, for instance update_pre_8.0.

I opened #26234 for that.

comment:6 Changed 18 months ago by gk

Keywords: TorBrowserTeam201806 added; TorBrowserTeam201805 removed

Moving our tickets to June 2018

comment:7 Changed 17 months ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201806 removed

Moving first batch of tickets to July 2018

comment:8 Changed 17 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201807 removed

comment:9 Changed 16 months ago by boklm

The update "watershed" seems to be working correctly for the alpha. A 8.0a8 browser is first being updated to 8.0a9 before being updated to 8.0a10.

comment:10 Changed 15 months ago by gk

Resolution: fixed
Status: newclosed

We are done here \o/.

Note: See TracTickets for help on using tickets.