Bug 20998 - Xamarin Studio 5.1 breaks Mac app sandboxing
Summary: Xamarin Studio 5.1 breaks Mac app sandboxing
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Mac Add-in ()
Version: 5.1
Hardware: Macintosh Mac OS
: High normal
Target Milestone: 5.3
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2014-07-01 06:12 UTC by John Conners
Modified: 2014-08-06 13:45 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Sample project to demonstrate the regression (21.80 KB, application/zip)
2014-07-01 06:12 UTC, John Conners

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description John Conners 2014-07-01 06:12:08 UTC
Created attachment 7244 [details]
Sample project to demonstrate the regression

The update to Xamarin Studio breaks sandboxing, simple as that.

Attached is a newly created project with the only changes being the sandbox entitlements switched on (and the Client permission). If you do a release build on Xamarin Studio 5.1 and check if it's sandboxed (eg. RB App Checker Lite or run it from Applications to see if it creates a container) you'll note that it doesn't. Downgrade to Xamarin Studio 5.0, rebuild and note that this time the app is indeed sandboxed as it should be.

Note that you'll need developer ID certificates on your system to test it properly.

Also note that I've tried this on two machines and seen the same problem on both. Am running on OS X Mavericks 10.9.3 with everything updated.
Comment 1 Chris Hamons 2014-07-01 11:00:40 UTC
I can confirm that sandboxing is broken on the latest version.
Comment 2 Chris Hamons 2014-07-01 12:37:21 UTC

I have a work around to get you up and running until a fix can be developed and pushed out to stable.

If you bring up the errors pad and click "build output", you'll notice a bunch of lines of commands during the build. One of them will look similar to:

codesign -v --force --sign "Mac Developer: Chris Hamons (#######)" "--resource-rules=/Users/donblas/Downloads/TestSandboxing/TestSandboxing/bin/Release/TestSandboxing.app/Contents/ResourceRules.plist" "/Users/donblas/Downloads/TestSandboxing/TestSandboxing/bin/Release/TestSandboxing.app"

The problem is that the command is missing:

--entitlements "PATH_TO_Entitlements.plist"

If you add the full absolute path instead of PATH_TO_Entitlements.plist and run that command in the terminal, your app should be correctly sandboxed.

I'm going to work on a fix to Xamarin Studio to fix this, but as I noted it will take a nontrivial amount of time to reach you.

Let me know if that doesn't work for you.
Comment 3 Chris Hamons 2014-07-01 13:17:05 UTC
Another thing I've noticed that may be useful. 

The issue appears to be related to trouble finding the "Provisioning profile". If you right click your project, properties, select Mac Signing, and then select a specific "Provisioning profile" instead of the default Automatic, your issue might be worked around as well.

We should be doing a better job either reporting an error or selecting the correct profile (so this still is a bug).
Comment 4 Chris Hamons 2014-07-01 14:58:22 UTC
Alright, it appears the real bug is that we don't warn if you select signing \ entitlements but have provisioning set to None. In the stable version, I can "fix" this issue by setting a non-None provisioning option.

We should at least warn in this case.
Comment 5 Chris Hamons 2014-07-01 16:00:01 UTC
Promoted to a build error in master \ 8b4bcf7b2fea73e6d99b06646d40cff10d0b1e68.

It will make its way to stable after some time, but selecting a provisioning profile is the correct solution either way.
Comment 6 Jeffrey Stedfast 2014-07-01 16:08:07 UTC
you might be able to try proposing this change for 5.2
Comment 7 John Conners 2014-07-01 17:32:01 UTC
Thanks for the workaround Chris. And picking a provisioning profile does indeed allow me to proceed.

As an aside, in my app not being able to sandbox without a provisioning profile is not a problem as my embedded login helper (which I don't want to use a provisioning profile to sandbox as I don't believe it would be accepted to the app store) is written in Objective-C (and XCode lets me sandbox without a PP), but if I were building a Xamarin.Mac helper app (admittedly unlikely) that I'd want to sandbox without a PP then the command line argument workaround is fine, albeit not as nice as 5.0 behaviour.
Comment 8 Chris Hamons 2014-07-02 09:17:53 UTC
I filed this bug:


so we don't forgot to look at allowing that use case in the future.