Open Bug 1781813 Opened 2 months ago Updated 2 months ago

Investigate using alternate method to modify policies before launch

Categories

(Testing :: mozregression, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: zeid, Assigned: zeid)

References

Details

Starting in macOS 13, creating a policies.json file in the app directory will no longer work, due to additional System Integrity Protection. Firefox will likely be updated to support a new approach for setting policies via a file on macOS, however we will need to find a way to override policies for all prior versions, e.g. via user defaults system / plist, or otherwise.

This is needed in order to at least disable automatic app updates.

So the "proper" way to do policies on macOS is through configuration profiles. It might be that policies.json just isn't a think on macOS anymore.

That's what I was thinking (i.e. this) -- I don't know if there's a super straightforward way to do this without overriding existing profiles / defaults on the system. It would be nice if we could namespace all domains for mozregression-triggered binaries (which may not be possible). Exporting/re-importing feels hacky.

One possible workaround that I have no way of testing on Ventura right now is to resign the app bundle after updating the policies file. Something like this might work:

diff --git a/mozregression/launchers.py b/mozregression/launchers.py
index 7d0c1ed..b6fbf2e 100644
--- a/mozregression/launchers.py
+++ b/mozregression/launchers.py
@@ -185,6 +185,7 @@ class MozRunnerLauncher(Launcher):
 
     def _disableUpdateByPolicy(self):
         updatePolicy = {"policies": {"DisableAppUpdate": True}}
+        basedir = os.path.dirname(self.binary)
         installdir = os.path.dirname(self.binary)
         if mozinfo.os == "mac":
             # macOS has the following filestructure:
@@ -192,11 +193,14 @@ class MozRunnerLauncher(Launcher):
             #     PackageName.app/Contents/MacOS/firefox
             # we need policies.json in:
             #     PackageName.app/Contents/Resources/distribution
-            installdir = os.path.normpath(os.path.join(installdir, "..", "Resources"))
+            installdir = os.path.normpath(os.path.join(basedir, "..", "Resources"))
+            appdir = os.path.normpath(os.path.join(basedir, "..", ".."))
         os.mkdir(os.path.join(installdir, "distribution"))
         policyFile = os.path.join(installdir, "distribution", "policies.json")
         with open(policyFile, "w") as fp:
             json.dump(updatePolicy, fp, indent=2)
+        if mozinfo.os == "mac":
+            call(['codesign', '--force', '--sign', '-', appdir])

I'm still running Big Sur and it doesn't complain after running the above. I assume on Ventura it will either ask for privileged access or simply still fail for other reasons, but would be nice if someone can confirm.

The above can be tested by installing mozregression from source with pip install -e and applying this patch.

Edit: fixed the patch to re-sign after the json dump.

(In reply to Zeid Zabaneh [:zeid] from comment #3)

One possible workaround that I have no way of testing on Ventura right now is to resign the app bundle after updating the policies file.

I recommend not re-signing. We sign Firefox using multiple steps and do plan to make it more complex in the future. Specifically, we use entitlement files to sign some of the files and we plan to use different settings for the firefox and plugin-container executables. If the resigning doesn't match what we ship with, it could mask problems that are reproducible on official builds but not with mozregression because the entitlements can affect functionality. So we would want to make sure the re-signing matches how we ship Firefox, but older builds used different codesign settings so that would be additional work to get right.

And to match the shipped builds, you would also have to re-notarize the bundle which requires uploading it to Apple's servers and takes several minutes for a result.

Clearing the quarantine attribute might be the best workaround for now. Or could there be an option to opt-in to use a policy file and clearing the quarantine attribute? Edit: I forgot that wouldn't work because the policy is used to disable updates as you explained.

See Also: → 1783694
You need to log in before you can comment on or make changes to this bug.