search

p0deje / Maccy

Lightweight clipboard manager for macOS
https://maccy.app
MIT License
12.68k stars 533 forks source link

Update error message due to possible Sonoma app sandboxing policy #720

Closed alexanderxc closed 7 months ago

alexanderxc commented 8 months ago

Before Submitting Your Bug Report

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:

Screenshot 2024-01-28 at 4 42 36 PM

Steps to Reproduce

  1. Install app
  2. Open settings
  3. Click update (on Sonoma)
alexanderxc commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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:

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 commented 8 months ago

https://github.com/p0deje/Maccy/commit/a0ee02e00db1fb4939d8ed88a8a8a2fada8b7269

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 commented 7 months ago

Please see https://github.com/sparkle-project/Sparkle/discussions/2514

p0deje commented 7 months ago

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 commented 7 months ago

Sparkle 2.6 has been released.

p0deje commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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? https://github.com/p0deje/Maccy/blob/5484768451e34f389007b4cc0aa2599816061225/Maccy/Maccy.entitlements#L4-L14

zorgiepoo commented 7 months ago

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 https://github.com/sparkle-project/Sparkle/discussions/2514 for more information on the issue.

zorgiepoo commented 7 months ago

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 commented 7 months ago

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!