Bug 1556733 Comment 43 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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

Back to Bug 1556733 Comment 43