1851948 - "Thunderbird.app is damaged and can't be opened..." After macOS Update to 13.5.1

Status: RESOLVED FIXED

(Thunderbird :: OS Integration, defect)

Description

[Haik Aftandilian [:haik]]

After updating to macOS 13.5.1 @mconley ran into a problem where both Firefox and Thunderbird were failing to launch. We didn't capture logs to debug Firefox, but some logs were collected to debug Thunderbird. The error is '“Thunderbird.app” is damaged and can’t be opened. You should move it to the Trash.'.

This was on Thunderbird 117.0b6, after updating macOS to version 13.5.1.

On Firefox, we've seen this problem after OS updates in some cases due to bug 1799332 which is being worked on now. In that bug, a modified file in the .app bundle breaks the codesigning signature causing macOS to fail to launch the app with the same error message.

Running $ codesign -vvvv /Applications/Thunderbird.app validates the signature of the bundle and reports problematic files.

Note: macOS tolerates some modification of files in the .app bundle and continues to launch the app without rechecking the signature every launch. However, after an OS update is one situation where we see signature re-checking. As a result, modification of files or additional files in the .app bundle can cause the application to fail to launch with this message after an OS update.

In this case, I suspect the update log files and extension listed below were causing the signature check to fail resulting in the launch failure. The update directory from the Troubleshooting Information page was reported as /Users/mconley/Library/Caches/Thunderbird/updates/Applications/Thunderbird.

$ codesign -vvvv /Applications/Thunderbird.app
--prepared:/Applications/Thunderbird.app/Contents/MacOS/rnpkeys
--validated:/Applications/Thunderbird.app/Contents/MacOS/rnpkeys
<omitting files for brevity>
--prepared:/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter
--validated:/Applications/Thunderbird.app/Contents/Library/Spotlight/thunderbird.mdimporter
/Applications/Thunderbird.app: a sealed resource is missing or invalid
file added: /Applications/Thunderbird.app/Contents/MacOS/updates/backup-update.log
file added: /Applications/Thunderbird.app/Contents/MacOS/active-update.xml
file added: /Applications/Thunderbird.app/Contents/MacOS/updates/0/update.status
file added: /Applications/Thunderbird.app/Contents/MacOS/updates/last-update.log
file added: /Applications/Thunderbird.app/Contents/MacOS/updates.xml
file added: /Applications/Thunderbird.app/Contents/Resources/distribution/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi

From https://developer.apple.com/videos/play/wwdc2022/10096/

Gatekeeper checks the integrity of newly-downloaded apps. In macOS Ventura, Gatekeeper will now check the integrity of all notarized apps, not just quarantined apps.

First, apps need to be properly signed. Starting with macOS Ventura, if your notarized app is no longer validly signed, it will be blocked by Gatekeeper on first launch. You should sign all your executables and bundles and ensure that their signatures stay valid when you make changes to your apps. In addition to an integrity check, Gatekeeper will also prevent your app from being modified in certain ways."

Comment 1

[Haik Aftandilian [:haik]]

Attachment: Example of the error message for Firefox Nightly

Comment 2

[Nick Alexander :nalexander [he/him]]

This looks like UpdRootD is in GreD, which on newer macOS will never work. On my Firefox Nightly, UpdRootD is

 /Users/nalexander/Library/Caches/Mozilla/updates/Applications/Firefox Nightly 

If this isn't the default on Thunderbird, they may have to migrate their users.

/cc :bytesized, who knows the most about migrating UpdRootD.

Comment 3

[Haik Aftandilian [:haik]]

For both apps, checking users of XRE_UPDATE_ROOT_DIR, and the docs for it here, when we fail to get XRE_UPDATE_ROOT_DIR, we fallback to using the app dir as the update dir. If that's what is happening here, the question would be what would cause us to fail to get XRE_UPDATE_ROOT_DIR.

Comment 4

[Robin Steuber (she/her) [:bytesized]]

(In reply to Nick Alexander :nalexander [he/him] from comment #2)

This looks like UpdRootD is in GreD, which on newer macOS will never work. On my Firefox Nightly, UpdRootD is

 /Users/nalexander/Library/Caches/Mozilla/updates/Applications/Firefox Nightly 

Is it? Comment 0 says:

The update directory from the Troubleshooting Information page was reported as /Users/mconley/Library/Caches/Thunderbird/updates/Applications/Thunderbird.

But clearly update files are ending up in the app bundle and I'm not really sure how. Maybe a previous version wrote update data there and it never actually gets removed on update?

---

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

For both apps, checking users of XRE_UPDATE_ROOT_DIR, and the docs for it here, when we fail to get XRE_UPDATE_ROOT_DIR, we fallback to using the app dir as the update dir. If that's what is happening here, the question would be what would cause us to fail to get XRE_UPDATE_ROOT_DIR.

I see that that comment suggests that we ought to do that (and that comment should be updated because we really shouldn't do that on macOS). But it doesn't look to me like we actually do that.

Comment 5

[Haik Aftandilian [:haik]]

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

For both apps, checking users of XRE_UPDATE_ROOT_DIR, and the docs for it here, when we fail to get XRE_UPDATE_ROOT_DIR, we fallback to using the app dir as the update dir. If that's what is happening here, the question would be what would cause us to fail to get XRE_UPDATE_ROOT_DIR.

I see that that comment suggests that we ought to do that (and that comment should be updated because we really shouldn't do that on macOS). But it doesn't look to me like we actually do that.

Could this code in nsUpdateDriver.cpp cause it?

Comment 6

[Robin Steuber (she/her) [:bytesized]]

Didn't know that was there. That should probably be removed. I can't think of any good that could come of it being there.

But no, I don't think that could cause this. The next step in the process is to spawn a thread and call into ProcessUpdates, which decides how to invoke the updater based on the contents of the update status file. So unless the Application Update Service wrote an update status file there, that ProcessUpdates call is going to see that the file is missing and exit without doing anything.

Comment 7

[Wayne Mery (:wsmwk)]

Did you make progress?

Comment 8

[Haik Aftandilian [:haik]]

I haven't been able to debug any further on this. I am leaving the needinfo and plan to get back to this.

Comment 9

[Wayne Mery (:wsmwk)]

Rob, :spol in Bug 1882116 suggests porting the following to Thunderbird - Bug 1799332 - Code signing failure due to wrong version of channel-prefs.js after update (macOS Ventura)

Comment 10

[Rob Lemley [:rjl]]

Bug 1799332 was already ported to Thunderbird in bug 1870378. It landed in Milestone 125 (February 2024). Most of this bug is from well before that.

Comment 11

[Stephen A Pohl [:spohl]]

(In reply to Rob Lemley [:rjl] from comment #10)

Bug 1799332 was already ported to Thunderbird in bug 1870378. It landed in Milestone 125 (February 2024). Most of this bug is from well before that.

Thank you for the heads up. I'm closing this as fixed by bug 1870378. Please reopen in case this occurs again after reinstalling Thunderbird, in which case there may be a need for a Thunderbird-specific patch.