Closed Bug 1556733 Opened 4 months ago Closed 3 months ago

[10.15] Multiple "Firefox Nightly Software Update" Mac OS X quarantine dialogs when performing a software update

Categories

(Toolkit :: Application Update, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox-esr60 68+ fixed
firefox67 --- wontfix
firefox68 + verified
firefox69 + verified

People

(Reporter: marcia, Assigned: haik)

References

(Blocks 1 open bug)

Details

Attachments

(8 files)

Seen while running the first developer beta of 10.15. Not exactly sure where to house this one. Also this may be just an early issue that goes away in subsequent betas.

STR:

  1. Check for updates for nightly
  2. Receive the dialog in attachments
  3. Update the browser
  4. Receive the same dialog in attachments again
  5. Updates successfully

My security permissions haven't changed since I updated from 10.14.6. They are set to "App Store and Identified Developers."

The same thing happens with beta as well.

Haik, this looks like the early incarnation of the notarization requirement in 10.15. What do you think?

Flags: needinfo?(haftandilian)
Priority: -- → P3

(In reply to Jim Mathies [:jimm] from comment #2)

Haik, this looks like the early incarnation of the notarization requirement in 10.15. What do you think?

I agree. It's probably related to changes in 10.15 where we expect apps to be required to be "notarized" with Apple's Notary Service. I can take this bug and look into it.

Releng is working on integrating the Notary Service into the workflow and we have bug 1470607. We can try testing with a notarized build and see if this problem goes away.

Normally, a message like this is seen for the browser the first time the user runs it after downloading (without the Q_DETAIL... text), but we don't normally see it for the updater.

Leaving the needinfo for myself to debug this.

See Also: → 1470607

Marcia, if you reinstall Nightly by deleting it and re-downloading, do you still see this when updating?

Flags: needinfo?(mozillamarcia.knous)

(In reply to Haik Aftandilian [:haik] from comment #4)

Marcia, if you reinstall Nightly by deleting it and re-downloading, do you still see this when updating?

Yes, I still see the issue when updating.

Flags: needinfo?(mozillamarcia.knous)
Blocks: catalina

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #5)

(In reply to Haik Aftandilian [:haik] from comment #4)

Marcia, if you reinstall Nightly by deleting it and re-downloading, do you still see this when updating?

Yes, I still see the issue when updating.

Thanks. I haven't been able to reproduce this on my 10.15 upgrade on a 2015 MacBook Air.

At this point, I don't know if the problem is related to notarization or another change in 10.15.

Aki has a notarized build available that you could try[1], but be aware that if it successfully updates, the new update will not be notarized and you might hit the problem again." If you are able to test this binary, it would provide some data about whether or not the problem is related to Notarization.

  1. https://queue.taskcluster.net/v1/task/CPsrzLb_QG-W9xR-PEQTzQ/runs/0/artifacts/public/build/target.dmg
Flags: needinfo?(mozillamarcia.knous)

I downloaded that build, but when I try to check for updates the log says "AUS:SVC Checker:onLoad - number of updates available: 0"

Flags: needinfo?(mozillamarcia.knous)

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #7)

I downloaded that build, but when I try to check for updates the log says "AUS:SVC Checker:onLoad - number of updates available: 0"

OK. Unfortunately we don't have an update-able Notarized build for testing right now. We should revisit this once that is available.

In the meantime, the updater team may have some better recommendations for how to debug this.

@rstrong, I can revisit this when we have update-able Notarized builds available, but pinging you here in case you would like to triage this to someone with more experience debugging Mac updater issues. (We don't have a firm date on when we will turn on Notarization for the Nightly channel yet.)

Flags: needinfo?(haftandilian) → needinfo?(robert.strong.bugs)

Here are some steps to test updates with a notarized build:

  • download en-US or de Nightly. These are builds from the try server and are notarized
  • before starting Nightly change the update channel by adjusting Firefox Nightly.app/Contents/Resources/defaults/pref/channel-prefs.js to use pref("app.update.channel", "nightly");
  • we need to modify the app.update.url pref to use the staging update server, but can't use about:config. Instead
    • open the Developer Tools, use the ... button to go to Settings. Scroll to the bottom and check Enable browser chrome and add-on debugging toolboxes
    • open the Scratchpad (menu Web Developer > Scratchpad), switch to the Browser context using the Environment menu
    • paste in Services.prefs.getDefaultBranch(null).setCharPref("app.update.url", "https://stage.balrog.nonprod.cloudops.mozgcp.net/update/6/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%SYSTEM_CAPABILITIES%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml"); alert('update url modified');
    • use the Run button to execute the code. Close Scratchpad.
  • Check for updates, it should find a complete. The buildID would increase from 20190604214120 to 20190605012540.

Thanks Nick!

Marcia, please try the steps provided by Nick and using the dmg provided by Haik in comment #6 to see if it happens with the notarized build as well. Thanks!

Flags: needinfo?(robert.strong.bugs) → needinfo?(mozillamarcia.knous)

Nick - I began the process in Comment 9. After I edited the Channel in Step 2, when I tried to open nightly it said it was "damaged" and I could not proceed.

Flags: needinfo?(mozillamarcia.knous)

Probably you could launch Nightly once to get the gatekeeper check out of the way, then modify channel-prefs.js. Even better is to also tweak the channel in the scratch pad:

Services.prefs.getDefaultBranch(null).setCharPref("app.update.url", "https://stage.balrog.nonprod.cloudops.mozgcp.net/update/6/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%SYSTEM_CAPABILITIES%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml"); 
Services.prefs.getDefaultBranch(null).setCharPref("app.update.channel", "nightly");
alert('update url and channel modified');

FWIW, the update history will say "Install failed" despite it succeeding. This is just because Firefox noticed the channel changed back to nightly-try (error 92). This wouldn't happen with real nightlies.

I followed Nick's excellent steps in Comment 9. I can confirm that I continue to see the dialogs even using the notarized build.

Haik, is the updater inside the bundle also notarized? Any ideas as to what is causing this and how it can be fixed?

Flags: needinfo?(haftandilian)

(In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #14)

Haik, is the updater inside the bundle also notarized?

The older scripts we were using do one notarization that covers all executables within the bundle. We shouldn't have to notarize the updater separately so I think we're OK in that respect.

Any ideas as to what is causing this and how it can be fixed?

I think this is due to a new policy in 10.15 where quarantined applications from .app bundles that are spawned not by Launch Services (for example with exec/posix_spawn as opposed to via the Finder) require an approval. Previously they did not. This was announced this week at WWDC in the "Advances in macOS Security" [1] presentation. I'll attach a screenshot of the page from the presentation. Apps are quarantined when they are downloaded and the downloading application marks them as quarantined as is the case with Firefox/Safari/Chome.

Our updater might fall into this category because it probably isn't launched with Launch Services (probably with exec or posix_spawn - I couldn't find where in the tree after a quick check) and it is going to be quarantined when downloaded.

If this is the reason, downloading Firefox via the curl(1) command should avoid the problem because curl doesn't set the quarantined flag. For example $ curl -O https://ftp.mozilla.org/pub/firefox/nightly/2019/06/2019-06-07-09-51-18-mozilla-central/firefox-69.0a1.en-US.mac.dmg downloads a Nightly dmg without marking it as quarantined. The xattr command can be run to determine if a file is quarantined or not: $ xattr firefox-69.0a1.en-US.mac.dmg.

@Marcia, sorry to ask you to test again. Would it be possible to download Nightly via the curl command above and see if the problem reproduces in that scenario?

Assuming that is the problem, there may be another way we can launch the updater that avoids the prompt. Or another workaround might be shipping the updater executable as a standalone binary within Firefox.app, not within its own updater.app. Though Apple might make this change apply to standalone binaries in a future release.

  1. Advances in macOS Security
    https://developer.apple.com/videos/play/wwdc2019/701/
Flags: needinfo?(haftandilian) → needinfo?(mozillamarcia.knous)

I tried downloading the build using the curl command, but I still got the dialogs. I did use the same test profile I had before - not sure if that matters or not.

Flags: needinfo?(mozillamarcia.knous)

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #17)

I tried downloading the build using the curl command, but I still got the dialogs. I did use the same test profile I had before - not sure if that matters or not.

Thanks. I don't know what is causing this, but it does seem quarantine related. I'll take this bug and do some more research on how quarantining works.

Assignee: nobody → haftandilian
Flags: needinfo?(haftandilian)
Summary: [10.15] Multiple "Firefox Nightly Software Update" dialogs when performing a software update → [10.15] Multiple "Firefox Nightly Software Update" Mac OX X quarantine dialogs when performing a software update
Summary: [10.15] Multiple "Firefox Nightly Software Update" Mac OX X quarantine dialogs when performing a software update → [10.15] Multiple "Firefox Nightly Software Update" Mac OS X quarantine dialogs when performing a software update
Flags: needinfo?(haftandilian)
Duplicate of this bug: 1559967

Here is the latest dialog I am getting in Beta 2.

The app can be opened by control-clicking the app, and then select 'Open' from the menu that comes up.

Can someone tell me where the 'Firefox Software Update' file is? That way I can try to use the same trick on that, instead of always downloading a full new Firefox.

(In reply to Matthias Schroder from comment #22)

The app can be opened by control-clicking the app, and then select 'Open' from the menu that comes up.

Can someone tell me where the 'Firefox Software Update' file is? That way I can try to use the same trick on that, instead of always downloading a full new Firefox.

No, you would need to go to Security & Privacy in Settings and then authorise the component, a new popup will show asking you to let the Firefox Updater... you allow it... nothing happens... you try to restart the browser and the loop starts anew.

(In reply to Goffredo Marocchi from comment #25)

...
No, you would need to go to Security & Privacy in Settings and then authorise the component, a new popup will show asking you to let the Firefox Updater... you allow it... nothing happens... you try to restart the browser and the loop starts anew.

Yes, I noticed that the Security & Privacy option did not work as advertised, I still have some hope I can run the Updater directly once I know where it is located.

As a temporary workaround to allow you to use Firefox on MacOS Catalina 10.15 (19A487I):

  1. Open a finder window.
  2. Click on Applications.
  3. Right click on Firefox / Nightly and select "Show Package Contents".
  4. Right click on "Firefox Software Update" and press "Move to Trash".
  5. Launch Firefox as normal.

You will no longer be blocked by the error messages stating that the "Software Updater" was blocked from opening.

Obviously you will no longer receive automatic updates but if like me you rely on Firefox and need Catalina for development, this works until this bug is resolved.

Duplicate of this bug: 1560093

hello,

i have the same problème and after put "software update" in trash my firefox work now

(In reply to Phillip Munn from comment #27)

As a temporary workaround to allow you to use Firefox on MacOS Catalina 10.15 (19A487I):

  1. Open a finder window.
  2. Click on Applications.
  3. Right click on Firefox / Nightly and select "Show Package Contents".
  4. Right click on "Firefox Software Update" and press "Move to Trash".
  5. Launch Firefox as normal.

You will no longer be blocked by the error messages stating that the "Software Updater" was blocked from opening.

Obviously you will no longer receive automatic updates but if like me you rely on Firefox and need Catalina for development, this works until this bug is resolved.

Can confirm this workaround works to launch Nightly on Catalina

This issue also affect Widevine plugin: I tried to play a song on Apple Music website and got a message telling me that libwidevinecdm.dylib could not be executed because it comes from an unknown developer.

We're still debugging this problem, but I think I've narrowed down the updater issue to being quarantine related. We launch the updater using NSTask and one of the documented changes in 10.15 is that quarantined apps launched with NSTask now trigger gatekeeper.

With the LSFileQuarantineEnabled key removed from Firefox.app/Contents/Info.plist I am able to update. However, first any downloaded updates must be removed and after the update, the Info.plist changes will be reverted and hence the workaround will have to be reapplied for the next update.

This changed stopped the libwidevinecdm.dylib issue reported on comment 31, but it led to the Widevine cdm crashing before it could be used.

I don't recommend applying this workaround because quarantining is a security feature and this temporarily disables it, but it might be useful to confirm whether or not this resolves the problem for you. This will have to be repeated for each update. (Replace Firefox.app with the right bundle name for the version you're using. For example, Firefox Nightly.app.)

  1. Quit Firefox.
  2. Remove the following lines from Firefox.app/Contents/Info.plist
<key>LSFileQuarantineEnabled</key>
<true/>
  1. Remove the update directory ~/Library/Caches/Mozilla/updates
  2. Launch Firefox and check for updates.

(In reply to gauthier.pogam-lemontagner from comment #31)

This issue also affect Widevine plugin: I tried to play a song on Apple Music website and got a message telling me that libwidevinecdm.dylib could not be executed because it comes from an unknown developer.

There is also a bugzilla ticket for the Widevine issue: bug 1558924

By the way, the workaround of bug 1558924 also works to get updates in Firefox again. So it's a far better workaround than deleting the updater.

See Also: → 1558924

It's possible that we need to staple a notarization ticket to Contents/MacOS/updater.app (as well as crashreporter.app & plugin-container.app). We are stapling only Firefox.app at the moment. We'll know more after we deploy notarization for nightly.

Haik asked me to test the notarized build again after the update to Beta 2. I followed the same set of steps in Comment 9. I did still get the software update dialogs that have been noted earlier. Happy to test when it is deployed to nightly again, or if there is a way to do another build with what Nick mentions in Comment 34.

(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #34)

It's possible that we need to staple a notarization ticket to Contents/MacOS/updater.app (as well as crashreporter.app & plugin-container.app). We are stapling only Firefox.app at the moment. We'll know more after we deploy notarization for nightly.

Do you have a ETA on when those will be available? Catalina is rolling to Public Beta next week so it would be nice if Nightly could benefit from more users testing it which they cannot currently without workarounds.

I'm intending to test a build where Firefox doesn't quarantine the downloaded updater.app files (or de-quarantines them immediately after downloading). Note that Notarization isn't expected to be a bypass of the Gatekeeper prompt. Notarized apps still trigger a Gatekeeper prompt on first launch, but the prompt is different and will allow launching the app on 10.15.

After changing nsUpdateDriver.cpp:CopyFileIntoUpdateDir() to use the copyfile(3) libc function instead of nsIFile::CopyToNative() to copy the updater to the ~/Library/Caches staging area, I am not seeing the Gatekeeper prompt during updates. I'm going to do some more testing and then post a build (with functioning updates) for testing.

hello,

the Bug with "software update" are not resolved with 67.0.4 on beta 2 mac OS catalina
we need always "Firefox Software Update" To "Move to Trash".

best regard

@Christian: As you can see the ticket is still open but someone is working on a solution. And no, there is no need to remove the updater, see comment #33.

(In reply to Phillip Munn from comment #27)

As a temporary workaround to allow you to use Firefox on MacOS Catalina 10.15 (19A487I):

  1. Open a finder window.
  2. Click on Applications.
  3. Right click on Firefox / Nightly and select "Show Package Contents".
  4. Right click on "Firefox Software Update" and press "Move to Trash".
  5. Launch Firefox as normal.

You will no longer be blocked by the error messages stating that the "Software Updater" was blocked from opening.

Obviously you will no longer receive automatic updates but if like me you rely on Firefox and need Catalina for development, this works until this bug is resolved.

This worked for me! I did not do the "Empty Trash" though, I just left the updater in there.

(In reply to Haik Aftandilian [:haik] from comment #38)

After changing nsUpdateDriver.cpp:CopyFileIntoUpdateDir() to use the copyfile(3) libc function instead of nsIFile::CopyToNative() to copy the updater to the ~/Library/Caches staging area, I am not seeing the Gatekeeper prompt during updates. I'm going to do some more testing and then post a build (with functioning updates) for testing.

It's not clear why, but after more testing of the fix that used copyfile(3) instead of nsIFile::CopyToNative(), I found that wasn't sufficient to avoid the Gatekeeper dialog. This might have been due to a reboot or a bug in 10.15. Using either copyfile() or nsIFile, the quarantine attribute is added to the updater when it's copied.

However, clearing the quarantined attribute with removexattr(2) after copying the updater to the staging area is working reliably in my tests on 10.15 Beta 2. I've also tested this fix on 10.9, 10.10, 10.12, and 10.14. I'll post a patch shortly for review.

We're seeing this now in 10.15 because of the documented changes in 10.15 regarding launching quarantined apps (see comment 12). It affects the updater because we copy it to a new location before launching it. The copying causes it to be quarantined due to Firefox's use of "LSFileQuarantineEnabled" in our Info.plist.

:rstrong commented that we shouldn't need to copy the updater.app to the staging area before we run on macOS, but we won't change this here because want to keep this fix small so its more suitable for uplift. Will file another bug to address the copying.

On Mac, remove the "com.apple.quarantine" extended attribute from the updater after it is copied to the staging area. Required on macOS 10.15 which has new restrictions on launching quarantined applications.

it is time that mozilla makes the appropriate changes themselves because it is not up to the user to do all the other explorer they work except firefox that poses compatibility problems

(In reply to Christian from comment #45)

it is time that mozilla makes the appropriate changes themselves because it is not up to the user to do all the other explorer they work except firefox that poses compatibility problems

You are using one of the first beta of Mac OS Catalina, you cannot expect everything to work immediately, especially for a software with the complexity of Firefox. Devs provided us a temporary solution to be able to use Firefox despite the lack of support of Catalina as a temporary fix. They are investigating the best way to fix this issue, so be patient.

OS Beta have the purpose of highlight this kind of issues to let developers fix their software before the official release of the OS. If you are not willing to face this kind of situation and don't have the patience to wait for a fix, please do not use beta software or OS.

See Also: → 1561731
Pushed by haftandilian@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c35dfc593498
[10.15] Multiple "Firefox Nightly Software Update" Mac OS X quarantine dialogs when performing a software update r=rstrong,spohl

We decided to land this on Nightly rather than first posting a build to test here. The fix should be on Nightly later tomorrow .

For people that want to verify this you will need a build with the fix first and the next update after getting the build with the fix should no longer exhibit this bug.

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Verified the fix works

Status: RESOLVED → VERIFIED

Comment on attachment 9074073 [details]
Bug 1556733 - [10.15] Multiple "Firefox Nightly Software Update" Mac OS X quarantine dialogs when performing a software update r?rstrong,spohl

Beta/Release Uplift Approval Request

  • User impact if declined: On macOS 10.15, Firefox will fail to update and then fail to launch. More specifically, on macOS 10.15 (which is only available as a Beta release from Apple at this time, but is scheduled to release in the Fall), the user will be prompted with unexpected Gatekeeper prompts asking if they want to run the updater. If the user clicks OK, the update will download, but the updater will fail to run. After that, Firefox will no longer launch when it is opened by the user.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Note: the code is covered by automated tests, but not on macOS 10.15 and not all other supported macOS versions.

To reproduce: install Firefox Nightly on Mac running macOS 10.15 Beta and attempt to update.

  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The fix is low risk because it just attempts to remove the com.apple.quarantine filesystem extended attribute from the updater. If the call fails, the code continues as before. We don't expect the code changes to have any impact on macOS releases earlier than 10.15.
  • String changes made/needed: None

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: On macOS 10.15 (expected to release in the Fall), without the fix Firefox fails to update and then fails to launch.
  • User impact if declined: On macOS 10.15, Firefox will fail to update and then fail to launch. More specifically, on macOS 10.15 (which is only available as a Beta release from Apple at this time, but is scheduled to release in the Fall), the user will be prompted with unexpected Gatekeeper prompts asking if they want to run the updater. If the user clicks OK, the update will download, but the updater will fail to run. After that, Firefox will no longer launch when it is opened by the user.
  • Fix Landed on Version: 69
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The fix is low risk because it just attempts to remove the com.apple.quarantine filesystem extended attribute from the updater. If the call fails, the code continues as before. We don't expect the code changes to have any impact on macOS releases earlier than 10.15.
  • String or UUID changes made by this patch: None
Attachment #9074073 - Flags: approval-mozilla-esr68?
Attachment #9074073 - Flags: approval-mozilla-esr60?
Attachment #9074073 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Priority: P3 → P1

Comment on attachment 9074073 [details]
Bug 1556733 - [10.15] Multiple "Firefox Nightly Software Update" Mac OS X quarantine dialogs when performing a software update r?rstrong,spohl

Fixes update & launch failures on macOS 10.15 due to quarantine changes. Approved for 68rc1 and 60.8esr.

Attachment #9074073 - Flags: approval-mozilla-esr68?
Attachment #9074073 - Flags: approval-mozilla-esr60?
Attachment #9074073 - Flags: approval-mozilla-esr60+
Attachment #9074073 - Flags: approval-mozilla-beta?
Attachment #9074073 - Flags: approval-mozilla-beta+
QA Whiteboard: [qa-triaged]
Duplicate of this bug: 1562949

Environment: macOS 10.15 Beta (19A501i), MacBook Air (13-inch, 2017).

I reproduced the initial issue (dialog from comment20) using a nightly build prior to the fix. I did not get the same dialog when using a nightly after the fix (Fx69) and updating to latest Nightly also works without issues.

Using Fx68.0 RC though, I can't start the build, I get the following dialog: "Firefox" can't be opened because Apple cannot check it for malicious software. (see attachment)

Though I could start 68.0 RC on another machine (iMac) that has the old previous version of 10.15 beta (19A487m). I will check on two other machines that I have in the office and also on 68.0 RC build 2 which will be available tomorrow.

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #59)

Using Fx68.0 RC though, I can't start the build, I get the following dialog: "Firefox" can't be opened because Apple cannot check it for malicious software. (see attachment)

Though I could start 68.0 RC on another machine (iMac) that has the old previous version of 10.15 beta (19A487m). I will check on two other machines that I have in the office and also on 68.0 RC build 2 which will be available tomorrow.

Just saw that someone logged a bug (bug 1563631) on this so this is confirmed that 68.0 RC can't be used on 10.15 beta3. I also checked two more machines and I got the same result there. Any thoughts?

Flags: needinfo?(haftandilian)
Duplicate of this bug: 1563631

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #60)

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #59)

Using Fx68.0 RC though, I can't start the build, I get the following dialog: "Firefox" can't be opened because Apple cannot check it for malicious software. (see attachment)

Though I could start 68.0 RC on another machine (iMac) that has the old previous version of 10.15 beta (19A487m). I will check on two other machines that I have in the office and also on 68.0 RC build 2 which will be available tomorrow.

Just saw that someone logged a bug (bug 1563631) on this so this is confirmed that 68.0 RC can't be used on 10.15 beta3. I also checked two more machines and I got the same result there. Any thoughts?

Let's use bug 1563631 for this problem which unrelated to this updater issue.

Please ignore comment 62. I've re-opened bug 1563631.

Verified using an update from 68.0 RC to 68.0.1 RC and 68.0esr to 68.0.1esr, no errors appear after updating.
I am curious about 60 esr though. At this moment after updating from 60.7.2esr to latest (60.8.0esr) will result in users that can't open 60.8.0esr. Do we have a plan for 60esr as well?

Flags: needinfo?(haftandilian)

This fix should be in the release for 60.7.3 (per checkin comment 57). But ESR 60 is not Notarized so any release of ESR 60 signed after June 1st will not run on Catalina until we enable Notarization. Catalina is likely going to release before ESR 60 EOLs so we will have to uplift Notarization and several Catalina fixes to ESR 60.

Flags: needinfo?(haftandilian)
You need to log in before you can comment on or make changes to this bug.