[tbb-dev] significant ESR60 updater changes

[Mark Smith]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20180405/d943328d/attachment.sig>