Update error message due to possible Sonoma app sandboxing policy

[alexanderxc]

Before Submitting Your Bug Report

• I have verified that there isn't already an issue reporting the same bug to prevent duplication.
• I have seen the FAQ.

Maccy Version (see 'About' window)

0.29.4

macOS Version

14.3

Maccy Settings

This problem is unrelated with Maccy settings. It is a possibly due to Sonoma sandboxing policy and the use of Sparkle Downloader.

Description

Even on a fresh installation and no configuration, when search for unapt is triggered the following error message is shown:

Steps to Reproduce

1. Install app
2. Open settings
3. Click update (on Sonoma)

[alexanderxc]

PS. This is issue can be bypassed by accepting the security warning but I reckon it shouldn't be there in the first place.

[p0deje]

It could be due to a recent upgrade of Sparkle, but it should go away after accepting, this should only be a one-time issue. Does it persist with multiple updated?

[alexanderxc]

Hi there, thanks for the quick reply and hard work on Maccy, which is an amazing software.

I'm not sure it is an issue with Sparkle per se as:

• Other projects I have installed that use sparkle (e.g. iTerm) does not show any issue with the updater and update themselves correctly.
• I recall an article mentioning that sparkle framework may have issue with sandboxed application in Sonoma, as this is only supported by sparkle v2 APIs.

This is why I was curious about which version of sparkle was bundled with Maccy.

I did not confirm the version mismatch popup and cannot confirm if this a recurring error or if it goes away.

[p0deje]

a0ee02e

We migrated to use Spark 2.5 which is distributed as a Swift Package 3 months ago, this is why I believe it might complain. However, it should only complain just once. FWIW I haven't seen such an error myself during or after the upgrade, so maybe there is something on your end?

I recall an article mentioning that sparkle framework may have issue with sandboxed application in Sonoma, as this is only supported by sparkle v2 APIs.

Can you share the link

[zorgiepoo]

Please see sparkle-project/Sparkle#2514

[p0deje]

Reading through the issue, it looks like I would either need to run unsandboxed Sparkle or build it from sources with a custom bundle identifier. None of the options seem optimal to me. So far I lean towards keeping things as is and waiting for Sparkle 2.6 release.

[zorgiepoo]

Sparkle 2.6 has been released.

[p0deje]

As far as I understand, I would need to checkout Sparkle back to the source code (I switched to using it as a package at some point). Then it has to be manually built from the source with a custom build ID. @zorgiepoo Is there any way to keep using a package manager to build/pass build ID during the application building phase?

[zorgiepoo]

You do not need to use a custom bundle ID. Sparkle 2.6 and later disables sandboxing on the Downloader XPC Service by default and it was updated to use a new bundle ID. So you can use Sparkle 2.6 through a package manager.

Using a custom bundle ID for Sparkle's XPC Services and sandboxing the downloader XPC Service is optional and would require recompiling Sparkle from source, which seems less convenient for you.

[p0deje]

I am not that familiar with how Sparkle works internally. Does disabling sandbox on XPC Service affect Maccy sandbox in any way? Do I need to do something extra?

Maccy/Maccy/Maccy.entitlements

Lines 4 to 14 in 5484768

	<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.files.user-selected.read-only</key>
	<true/>
	<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
	<array>
	<string>$(PRODUCT_BUNDLE_IDENTIFIER)-spks</string>
	<string>$(PRODUCT_BUNDLE_IDENTIFIER)-spki</string>
	</array>
	</dict>

[zorgiepoo]

No, nothing extra.

XPC Services can be sandboxed (or not sandboxed in this case) differently from the main app (i.e, they provide privilege separation). They execute in different processes and are separate, but communicate with each other. You are already using Sparkle's installer launcher XPC Service which is not sandboxed for example (and does not have this issue). Maccy will continue to be sandboxed, just that the downloader XPC Service now won't be.

This is what I've been sending to a few other developers:

Due to a sandboxing issue new to macOS Sonoma and due to this app and other apps using Sparkle's Downloader XPC Service, users may see a one-time system warning dialog when checking for updates about "Downloader" differs from previously opened versions.

It looks like Maccy wants to use the Sparkle's Downloader XPC Service from following Sparkle's sandboxing guide because the app is not entitled with an outgoing network connection (com.apple.security.network.client) entitlement. So there are a couple ways to fix this issue:

• Maccy can update to Sparkle 2.6.0 or later (which disables sandboxing for the Downloader XPC Service by default to avoid conflicts) (easiest way)
• Maccy can re-compile their current version of Sparkle with a custom XPC_SERVICE_BUNDLE_ID_PREFIX

See sparkle-project/Sparkle#2514 for more information on the issue.

[zorgiepoo]

Another viable option I failed to mention before is enabling the Outgoing Network Connection (com.apple.security.network.client) entitlement on your app instead of enabling Sparkle's Downloader XPC Service (as there are other drawbacks with it, e.g. Sparkle can't use WebKit 2). I updated the sandbox documentation for the downloader service here.

Each option has its own upsides/downsides.

[p0deje]

I've upgraded to Sparkle 2.6 and will test how it works with the next release. @zorgiepoo Thank you very much for your help with this issue and your work on Sparkle!