Create a plan for releasing an update when Apple's notarization service is not available
Last year Apple introduced "notarization" into their app-signing process. We integrated this into our release process in legacy/trac#30126 (moved). 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).
- 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.
- 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?