Closed balthisar closed 3 years ago
It's possible you are accidentally sandboxing org.sparkle-project.InstallerLauncher.xpc
which should not be done. The deny log above seems to imply the XPC Service has a container:
"container": "/Users/jderry/Library/Containers/org.sparkle-project.InstallerLauncher/Data"
Which I'm not sure should be present.
The host application entitlements have been verified via codesign -d --entitlements :- {file} as being correct.
Please check this on the XPC Service inside your built app and verify it has no sandboxing entitlements applied.
Whoah, yeah, when I check it with codesign
, it has all of the host app's entitlements. I guess those are somehow embedded in the XPC itself, as they're present even if I move the XPC to the desktop.
Good catch on seeing the container in the log; I guess I see it so often I'm blind to it.
Any idea how to prevent Xcode from applying the entitlement? It's outside your scope, so feel free not to answer; I'll research that myself.
Thanks!
Are you using any scripts or invocations that use codesign --deep -s
by chance? Deep signing like this is discouraged because different components in an app may need different entitlements. Xcode is normally good about signing and exporting re-signed applications properly; inside-out and preserving entitlements. Our website docs have the workflow we recommend.
Ha! There it is:
OTHER_CODE_SIGN_FLAGS = --deep
Why the heck did I put that in there‽
Working perfectly for me. Thanks.
Description of the problem
tl;dr: the sandbox is preventing the InstallerLauncher.xpc from getting the bundle from my sandboxed application. This failure happens at
SUInstallerLauncher.m:329
, whereNSBundle *hostBundle = [NSBundle bundleWithPath:hostBundlePath];
This results in a nil assignment and failing the
assert()
a few lines later.Do you use Sandboxing in your app?
Yes.
Version of
Sparkle.framework
in the latest version of your appCommit hash 4054549, this is current as of today.
Version of
Sparkle.framework
in the old version of app that your users have (or N/A)n/a
Sparkle's output from Console.app
That's the output when I've got a signed application exported from the Organizer. Here's the output when I'm running attached to XCode:
Steps to reproduce the behavior
org.sparkle-project.InstallerLauncher.xpc
and not the other services.codesign -d --entitlements :- {file}
as being correct.Of course, I thought the whole point of using XPC was to have it escape from the sandbox. Why would sandbox even be preventing the XPC from getting at the bundle?