Closed Bug 1471004 Opened 6 years ago Closed 5 years ago

use apple notary service in signed builds release automation edition

Categories

(Release Engineering :: Release Automation: Signing, defect)

defect
Not set
normal

Tracking

(firefox-esr6069+ fixed, firefox-esr6868+ fixed, firefox68+ fixed, firefox69+ fixed)

RESOLVED FIXED
Tracking Status
firefox-esr60 69+ fixed
firefox-esr68 68+ fixed
firefox68 + fixed
firefox69 + fixed

People

(Reporter: kmoir, Assigned: mozilla)

References

Details

(Whiteboard: [releng:q12019])

Attachments

(11 files)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
I noticed bug 1470607 in our queue for build configs and thought there might be some corresponding work for the release automation that needed to be investigated

This applies to macOS 10.14, here is some further documentation
https://developer.apple.com/developer-id/
https://appleinsider.com/articles/18/06/06/inside-apples-move-to-ramp-up-security-privacy-in-ios-12-macos-mojave
Blocks: 1470607
Whiteboard: [releng:q12019]

Aki, Nick: I think you have already started looking at this.

Keywords: leave-open
Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6487aeb66175
use workerType aliases for signing. r=tomprince
Blocks: 1514903
Depends on: 1541565

Rob, Wayne:

This is close to deployment. We're hoping in the next couple weeks. This means:

  • all mac build-signing, nightly-l10n-signing, partner-repack-signing, and eme-free-signing tasks will run on a dedicated mac pool
    • these will mac-sign locally; once this lands this marks the beginning of the mac signing server EOL
    • these will widevine- and eventually omni.ja-sign via autograph
    • these will create pkg installers
    • on release trains, we'll notarize the apps as well. This is a new MacOS Catalina requirement.

We'll need to set up a similar pool for Thunderbird and determine whether you want/need notarization; I'm guessing yes.
LMK if you have questions.

This moves mac signing tasks to the notarization/iscript pool. It also
adds support for pkg installers and notarization.

Depends on D33856

Depends on D33857

For mac hardened runtime signing, we use an entitlements file that's now
in-tree. This patch passes the url for that file in the task definition.

The original patch for this was written by sfraser.

Depends on D33858

The relpro action requires a list for partner_subset and defaults to
[]. In get_partner_config_by_url we check to see if partner_subset, ignoring the subset if it's an empty list. We either
need to do the same thing in get_partner_config_by_kind, or we need to
allow for a null value in the action (or populate an empty
partner_subset with the partners from the partner config in the
action)

Depends on D33860

Attachment #9070084 - Attachment description: Bug 1471004 - add notarization workerType aliases. → Bug 1471004 - add notarization workerType aliases. r=nthomas
Blocks: 1558082

Bug 1501384 for the license agreement. Notarization is broken in the meantime.

(In reply to Aki Sasaki [:aki] from comment #13)

Bug 1501384 for the license agreement. Notarization is broken in the meantime.

This was fixed. Currently attempting staging releases to test updating from no-notarization -> notarized build -> 2nd notarized build. We've already done a bit of update testing, so if this continues to fail I may land and test on the nightlytest channel while mac nightly updates are frozen.

Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/34448603afab
add notarization workerType aliases. r=nthomas
https://hg.mozilla.org/mozilla-central/rev/0da56de412db
mac-signing transform logic + config. r=tomprince
https://hg.mozilla.org/mozilla-central/rev/2ad746de8d09
beetmove macosx pkg installer. r=sfraser
https://hg.mozilla.org/mozilla-central/rev/556f716a4517
add entitlements url for hardened runtime signing. r=tomprince
https://hg.mozilla.org/mozilla-central/rev/365cb98beddc
build_signing: macosx64-nightly -> macosx64-shippable. r=callek
https://hg.mozilla.org/mozilla-central/rev/d691e2174680
ignore partner_subset if it's an empty list. r=tomprince a=release

Mac updates are unfrozen.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Keywords: leave-open
See Also: → 1563631

I grafted 34448603afab..d691e2174680 on to release and esr68, and ran staging releases for 68.0.1 and 68.0.1esr, which went fine.

The task definitions specify the signing formats slightly differently (uses old widevine vs new autograph_widevine) but the scriptworker uses autograph regardless; there are also the old-style scopes which have been removed in 69, but these are ignored. The actual signing is done with the dep cert, and notarization isn't done, but that should work properly when the release scriptworker is in use.

Uplifting to esr60 would be more involved. D27400 is not already present there, and relies on other changes which would also need uplift; alternatively we could rework some of the new code.

Assignee: nobody → aki

Want to request release and esr68 uplift for this patch set? 68.0.1 is planned for this week.

Flags: needinfo?(nthomas)
Flags: needinfo?(aki)

Yes please. Attempting to set ? for those, hopefully that will autofill the approval comment?

Flags: needinfo?(nthomas)
Flags: needinfo?(aki)

Feature/regressing bug #: n/a, for macos catalina
User impact if declined: macos catalina users will not be able to run release/esr builds
Describe test coverage new/current, TBPL: https://jira.mozilla.com/browse/PI-170
Risks and why: low risk, we've already shipped betas with the new mac signing
String/UUID change made/needed: none

This component doesn't have approval flags enabled. Would you prefer we enable those here, or should we do the approval via bz comments?

Flags: needinfo?(jcristau)
Flags: needinfo?(jcristau)
Flags: needinfo?(aki)

Good catch. We need to add it.

Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fa57eb4a347c
add esr support for entitlements. r=tomprince
Flags: needinfo?(aki)

a=jcristau for landing on release (for 68.0.1) and esr68 (for 68.0.1esr and 68.1.0esr)

I tested the signed mac build from Julien's push. Looks notarized. Also looks like RyanVM pushed to esr68 :)

(In reply to Daniel Varga [:dvarga] from comment #33)

https://hg.mozilla.org/mozilla-central/rev/fa57eb4a347c

You're going to put this onto mozilla-beta?

Flags: needinfo?(aki)

We can. There's no particular benefit other than consistency; the patch essentially adds esr support. Do you have a strong preference?

Flags: needinfo?(aki)

I just want to know whether our https://hg.mozilla.org/comm-central/rev/8a97b511da21 needs to go to beta, see bug 1558082 comment #18. But if it doesn't, we're done. No preference, well, if not needed, don't do it, it's documented now.

I rebased a patchset against esr60, which appears to do the right thing per taskgraph-diff.py. This is the four bug 1471004 patches and the one bug 1532710 patch in this try push.

I've tested on macOS 10.14.5 with try build from comment 41, but this is not notarized and the first-run dialog is the old one. Should this try build be notarized?

Flags: needinfo?(aki)

The try build is not notarized. We’ll get the first esr60 notarized builds after we uplift.

Flags: needinfo?(aki)

Julien, have you seen the thread "macOS Notarization and macOS 10.15 Catalina Uplifts Needed in ESR60" from July 24? We'd like to uplift mac notarization to esr60.

From Ritu:

Julien owns ESR60.9 so I'll let him have a final say. As such, all the fixes are not ready to uplift to ESR60 so we can wait until he is back from PTO (Aug 5th).

From Haik:

If the Catalina release was pushed out by 3 months, that would not affect ESR60.9 and we would not have to backout any patches.

Notarization is going to be required on macOS 10.15. On 10.14, it is optional. On earlier releases of macOS, it has no benefit and should not affect how the application works. So it would just mean that ESR 60.9 is a Notarized application which gives us some benefits on macOS 10.14 and has no impact on earlier macOS releases. (To be more specific, Apple has documented Notarization is ignored on earlier macOS releases, but there's always the possibility of bugs and this is why our QA efforts include testing on all macOS versions that we support.)

There would be two small benefits to Notarization even if Catalina slips:

  1. Users that download and launch the ESR on macOS 10.14 would see the Notarized first-run dialog which is a slight user experience improvement because the dialog is less cautionary. It's a small difference shown in this image (where the Notarized dialog is upper version.)
  2. ESR 60.9 would work on the Catalina Beta releases. Unless it is Notarized, any application signed after June 1st, 2019 will not launch on Catalina.
Flags: needinfo?(jcristau)

a=jcristau to get this patchset in 60.9.

Flags: needinfo?(jcristau)
Depends on: 1570581
See Also: → 1576733

Greetings and felicitations. When Firefox (v. 77.0.1 under macOS Catalina 10.15.5; I see that 78 is now available, but I can't get Firefox to update to it) starts up, I receive [https://www.flickr.com/photos/67341772@N04/50062886178/in/dateposted-public/ this error message].

I can still open Firefox if I click through the error message, but I would like to not have to.

I've opened bug 1649651 for that issue, please direct all replies there. Thanks.

You need to log in before you can comment on or make changes to this bug.