[tor-bugs] #33480 [Applications/Tor Browser]: Create a plan for releasing an update when Apple's notarization service is not available

[Tor Bug Tracker & Wiki]

#33480: Create a plan for releasing an update when Apple's notarization service is
not available
------------------------------------------+----------------------
     Reporter:  sysrqb                    |      Owner:  tbb-team
         Type:  defect                    |     Status:  new
     Priority:  Medium                    |  Milestone:
    Component:  Applications/Tor Browser  |    Version:
     Severity:  Normal                    |   Keywords:
Actual Points:                            |  Parent ID:
       Points:                            |   Reviewer:
      Sponsor:                            |
------------------------------------------+----------------------
 Last year Apple introduced "notarization" into their app-signing process.
 We integrated this into our release process in #30126. However, our
 current process assumes Apple's notarization service is highly-available.
 This is not always true, and in our experience it has frequent outages or
 slowness (but maybe we just have really bad timing).

 In our current release flow, as a result of our release process assuming
 notarization is "quick", we wait for Apple to notarize each package and
 then "staple" the notarization into each dmg. After this is completed, we
 regenerate the macOS mar files and then compute the hash of all of the
 signed packages (and then sign all of the individual files).

 I wonder if we can think about these last three steps again, particularly
 in a situation where we must get out an update as quickly as possible (I'm
 thinking like a chemspill).

 1. If we don't staple the notarization, then we can code-sign (gatekeeper)
 the packages and then continue with the remaining release steps (recreate
 mars and incrementals, signmars, hash, gpg sign) in parallel with waiting
 for notarization from Apple.
 1. We split the release between Windows/Linux/Android and macOS, where we
 release updates for the former platforms initially and we release updates
 for macOS when the packages are ready. This would require "teaching" some
 of our scripts if they should operate over al platforms or only a subset
 of them.

 The main disadvantage of (1) is that all macOS users will query Apple for
 checking the update's notarization. We want to limit the amount of
 information Apple learns about our users, and this enumeration is not
 good.

 The main disadvantage of (2) is additional complexity in our build/release
 process. Maybe the webserver's config needs changing, too?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33480>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online