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

https://hg.mozilla.org/mozilla-central/rev/6487aeb66175

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.

• current in-tree patchset
• iscript

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

Depends on D33859

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

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.

Mac updates are unfrozen.

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.

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

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

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?

Does https://hg.mozilla.org/try/rev/14fa1cda0e71b8e8b2595a672e2fef6248cd43e6#l1.16 intentionally exclude esr?

Good catch. We need to add it.

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

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

https://hg.mozilla.org/releases/mozilla-release/rev/2d0bfd677567
https://hg.mozilla.org/releases/mozilla-release/rev/61c20d63d900
https://hg.mozilla.org/releases/mozilla-release/rev/8cd93915bf33
https://hg.mozilla.org/releases/mozilla-release/rev/275786b6dbbc
https://hg.mozilla.org/releases/mozilla-release/rev/4d9343043408
https://hg.mozilla.org/releases/mozilla-release/rev/e74de06a2eb9
https://hg.mozilla.org/releases/mozilla-release/rev/45106a0c0a42

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

default (68.1esr):
https://hg.mozilla.org/releases/mozilla-esr68/rev/608359297e3fe77fe5ed8e57543d24242ff8ee2e
https://hg.mozilla.org/releases/mozilla-esr68/rev/c741fa80faaa123810293fb441cbff2536cade80
https://hg.mozilla.org/releases/mozilla-esr68/rev/25c573afcd27438ed8010707ee7b524be014a7a1
https://hg.mozilla.org/releases/mozilla-esr68/rev/9f3c24f60e799c293f35ca75940f980dcfcf4785
https://hg.mozilla.org/releases/mozilla-esr68/rev/07ea65ef9f1ab336918ddebcca2191475abbe063
https://hg.mozilla.org/releases/mozilla-esr68/rev/f0619c9d79229923c1c77fe41d151b50ed5177ba
https://hg.mozilla.org/releases/mozilla-esr68/rev/cf6798f00871a23458546e0b8b3a1366d5759ea6

FIREFOX_ESR_68_0_X_RELBRANCH (68.0.1esr):
https://hg.mozilla.org/releases/mozilla-esr68/rev/1b2ac76eec05464f33315710c7ad383017e2c967
https://hg.mozilla.org/releases/mozilla-esr68/rev/682939872bee09cc2f0f405a8f294df243ccd0f8
https://hg.mozilla.org/releases/mozilla-esr68/rev/3cc0b90500a4e60c21b9bbda72ad022ed547eb85
https://hg.mozilla.org/releases/mozilla-esr68/rev/ff059ad94ad02b05243687b27d76b272783770ed
https://hg.mozilla.org/releases/mozilla-esr68/rev/4cdcbf76a182b7595a14bfdbe7aca7b266403083
https://hg.mozilla.org/releases/mozilla-esr68/rev/c51e6af95b386dfbc7a491cc663e578593830b21
https://hg.mozilla.org/releases/mozilla-esr68/rev/61219aed2735afac3edcf590e69edbb463ca7372

(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?

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

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?

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

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.

a=jcristau to get this patchset in 60.9.

https://hg.mozilla.org/releases/mozilla-esr60/rev/bc4035b1a42e912c81d4f59b9380857cdd6d97b0
https://hg.mozilla.org/releases/mozilla-esr60/rev/13bb65d5ecf0260a3c13267f10a32ef55e137e2d
https://hg.mozilla.org/releases/mozilla-esr60/rev/69d62cb295efbb196ff42a67782ede0a6fc3a894
https://hg.mozilla.org/releases/mozilla-esr60/rev/4862f690ed5cc61785b15312db79a1c31c86f1e4

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.