Recently, Kathy and I spent some time looking at the changes that have been made to the Firefox updater since ESR52. The purpose of this message is to highlight a few of the most important changes. It would be helpful for other people on the team to review and comment on our assumptions.
1. "Simplify the application update UI" https://bugzilla.mozilla.org/show_bug.cgi?id=893505 The user experience has been streamlined. The big ugly update dialog has been removed and doorhangers are instead used to prompt people to update. We will want to adjust some prefs that control how soon users are nagged to update (to reduce the time, as we did with the older update UI) but Kathy and I think the new experience should be okay for Tor Browser users. There is a work item for later this year to work with our UX team to improve the update experience, but first we will need to get the ESR60-based one working.
2. "LZMA support for updater" https://bugzilla.mozilla.org/show_bug.cgi?id=641212 Within the MAR files, each file or patch is compressed. Prior to Firefox 60, BZip2 compression was used. By switching to LZMA, file size is reduced by 10-20% in most cases. Some size comparisons that were done for Firefox are available here: https://bugzilla.mozilla.org/show_bug.cgi?id=641212#c250 Kathy and I think we want this change for Tor Browser, but it will mean that we must execute a "watershed" (two-step) update process wherein older browsers must first update to a Tor Browser based on ESR60 before they can update to a newer version. In other words, we will need to provide old-format MAR files to old browsers so they can be updated to a browser that understands the new LZMA-based format. We have never done a watershed update for Tor Browser, so it will be exciting to try.
3. "Support stronger hash algorithms than SHA1 for signing certificates" https://bugzilla.mozilla.org/show_bug.cgi?id=1105689 Mozilla switched from SHA1 hashes for MAR files to SHA384. We have been using SHA512 for Tor Browser from the beginning (via patches to the Mozilla code). The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks. I am not a crypto person, but it seems to Kathy and me that switching to SHA384 is a win because we can eliminate some of our patches. If we are doing a watershed (two-step) update process to get the LZMA support, we can handle the SHA512 -> SHA384 transition at the same time. Mozilla did this same thing, adopting both incompatible changes to the MAR format together in Firefox 56.0 timeframe.
4. "Remove hashFunction and hashValue attributes" https://bugzilla.mozilla.org/show_bug.cgi?id=1373267 Mozilla removed support for a hash check of the MAR files that has historically been implemented by including hash values in the update manifest (XML) file that is returned by the update server. Mozilla relies on MAR signatures to verify the integrity of the Firefox MAR files, but in the past we have talked about the value in requiring that two things need to be compromised: the update server as well as a MAR signing key. For that reason, Kathy and I believe we should back out these changes and continue to have our update server return hash values.
As I mentioned above, your input is welcome. Thanks!
-Mark