I'm just trying to get some confirmation on Sandboxing. I understand exactly why it's been put in place and the principle behind it.
As I start to near the release of my first Mac App I kept putting off sandboxing as it sounded rather complicated and thought I'll worry about it nearer the time. I watched a couple of the Apple videos and read up on some of the documentation (not all) and thought I'd try and add it to my app!
I turned on sandboxing in Xcode, didn't specify any entitlements as they didn't really relate to my app and the entitlements certificate popped up on the left and ran my app....that was it, all ran fine without issues.
That's where I got confused...surely it can't be that simple?! My app saves data in the background, no user input to save, it just happens seamlessly. Anyway I checked /Users/whoever/Library/Containers and there was my app named container folder and the relevant data was saved there (although of course that wasn't the exact path I specified as the save location in my app). I closed my app, reopened it and sure enough the saved data was still there.
IS THAT IT? Does that now mean my app is sandboxed or am I missing something here?
Yes, that's it. If your app really doesn't need any entitlements, not even the ability to open/save files specified by the user, then it's trivial to sandbox.
Related
If an app is build in Flash/AIR and exported as Captive Runtime for OSX, how does one associate a filetype with that app without breaking codesigning?
In a more general sense, can one edit the Info.plist in any app without invalidating codesigning, or use some other signed installer to handle the associations (like one would do on windows) and then sign that?
The only way I've seen to associate the app with a filetype, so far, is via the guide at https://superuser.com/questions/178316/how-to-set-an-icon-for-a-file-type-on-mac
This, according to the comments there, does invalidate codesigning.
If an application is already codesigned with a valid signature and any changes are made to the signed contents of it's .app bundle it will come back as invalid. So to answer your question, changing one byte in a signed apps info.plist will invalidate the signature. Changing an .apps icon does not affect the codesignature nor does adding something else entirely into it's app bundle, strangely enough. Well, maybe not entirely strange — since those actions (presumably) won't be changing/manipulating the signed contents.
As for associating filetypes with your application, that is handled through LaunchServices. If you aren't able to specify the properties at build time (using an info.plist) then you can use a dynamic configuration instead.
I know there are many similar questions on StackOverflow, but I think I've read them all and none quite apply.
I have a Cocoa app that I am trying to sign for distribution on the Mac App Store. I have created my distribution profile and I believe it's all hooked up correctly in XCode. When I build the app, XCode prompts me about signing and the build finishes with no errors. When I look at the build messages, I see a happy green check mark from Code Sign.
Further, I'm using Receigen for the receipt validation, and when I use it to inspect my built app, it shows that the app is indeed signed and that the signature is valid.
However...when I copy the app to a different machine (running Snow Leopard, if that makes a difference) and launch the app there, I see that after the app quits with code 173 for receipt validation, Console shows that storeagent logs the message "Unsigned app." Similarly, when I inspect the app with Receigen, it shows that the app is signed but not valid. Why could this be?
Tangentially, in case it helps spur some ideas, the context of this is that I'm trying to get receipt validation working, and on my main dev box (the one in which the app shows as being signed correctly), when I exit with 173, I am prompted with the iTunes credential challenge, although the receipt is never retrieved from the store. On the other machine, I never even receive the credential challenge (I presume and hope this is all because of the same issue).
I'm really at wits' end here. Thank you, fine people of StackOverflow, for any ideas you might have.
For the record, the answer is in a comment from #Brian Rak:
Update: I finally got things working, but unfortunately, I was never
able to determine exactly what the issue was. However, it appears
something was configured incorrectly or corrupted somewhere in my
project file. I created a new project, copied all my source code and
resources into it, and rebuilt, and the problem magically went away.
My advice if you're seeing this would be to create a toy app that uses
the same bundle ID and if you can get it working, just proceed with
that one as I did.
I've just enabled sandboxing in my OS X application, and now my Core Audio code doesn't work. In particular, when I call AUGraphAddNode, it returns the error invalidComponentID, saying just "The operation couldn't be completed". A number of other Core Audio calls seem to work correctly before that, though.
It doesn't seem to be a direct sandbox violation, as there aren't any messages from sandboxd in Console, but it definitely works when I turn off sandboxing. Anyone know why this would possibly happen? The only thing I can imagine is that maybe it's trying to read files that I don't have access to, although I would think that would give me a sandboxing error.
Update:
To clarify, I've tried enabling every sandbox entitlement and the issue still occurs.
I've also narrowed down the issue somewhat. That call only fails if I try to add a node with the component type kAudioUnitType_MusicDevice and subtype kAudioUnitSubType_DLSSynth.
Update 2:
I've figured out a hacky workaround. If I add a temporary exception entitlement to enable read-write access to the user's entire home directory, the error no longer happens. This is obviously not ideal, so I'm continuing to search for better options. I tried to narrow down the access required by adding entitlements for more specific subdirectories, but that didn't work.
I recently submitted the app I was having this issue with to the app store, and it was rejected for using the temporary exception entitlement mentioned in the last update to my question. I was pointed to this article discussing this exact issue.
It turns out that there's another entitlement that's unfortunately not documented in the standard sandboxing documentation: com.apple.security.temporary-exception.audio-unit-host. This will allow audio units, like the DLSSynth, which require permissions greater than the host environment's sandboxing allows, to run in the host environment, provided that the user grants permission at run time.
I'm not sure how long-term this solution is, given that this entitlement is also categorized as a temporary exception, but according to Apple this is the way to go for now.
If you are using Core Audio for microphone input, don't forget to add this to the sandbox entitlements in both your Target Summary and app entitlements file.
This error can occur in audio unit host apps that have been sandboxed.
On Xcode 11, you can turn off Sandboxing by removing it from the Signing & Capabilities tab:
So I did something really stupid... I got a new MBP, and gave my old one to a friend. Before I did that, I transferred all of the contents of my big folders (Documents, Downloads, etc...) to my new Mac, and then I deleted the user on my old Mac. Unfortunately, I neglected to transfer the folder that contained the entire Xcode Project for my app that is currently on the App Store, as it wasn't in one of those folders, and I'm the only one who had it. The only way of being able to retrieve it that I thought of was that since I had to upload the binary to iTunes Connect to submit the app, Apple might still have it. Otherwise, I guess I'll have to completely start from scratch if I ever want to update it again. I just contacted Apple via iTunes Connect, but I was wondering if anyone has any idea of what I am able to do now, mainly, if Apple will actually give me all the files back. Thanks.
Any chance you've got a backup via timemachine?
Timemachine can't help you in the case of a fire (see http://github.com for what you can do about fires, hurricanes, tornadoes, volcanoes, or thieves), but maybe it can save your bacon right now. :)
Yeah, you pretty much lost it. I'd recommend looking at some source control - for example Github. It's built into XCode, and Github is pretty cheap for Private Repositories, and free for public ones.
You (nor Apple) won't be able to retrieve it from the binary.
No revision control system?!
You wiped your data or only simply deleted?
Because, here is a possibility retrieve data from the HDD (or at least some parts) when only simply deleted them. Delete usually does not wipe the data.
If you can get your old HDD, you should:
- insert it into external usb-HDD enclosure
- attach to your new MAC
- make an image from it to one big file (with the command "dd") (assuming than your new HDD is bigger than your old)
- and with several tools you can "try" recover some data
every use of the old HDD drastically lowering the chance recovering something from it.
Hi Im using Mac 10.5.8 . In my app im using my own keychain(created by me), but my actual question is when I modify my code in the app every time a prompt is appearing, saying that the present app is modified do you want to allow or not.Can any one tell how to supress this prompt(allow by default when ever I change the app).I couldn't find the solution in the documentation.
The Keychain has a list of trusted applications, and this list includes a hash digest for the application. When the application changes, it becomes untrusted again. This also happens with "big" applications like Camino.
There are two special measures to reduce this: When a shared library gets updated, the system will keep track of this and accept the application even after the update. Also, when Software Update updates an app, it will fix the digests as well (which is why Apple's own apps can get away without re-confirmation).
Update: If you sign your code, Keychain will also accept updated applications (signed with the same certificate).