De Tout Et De Rien

There is a lot of discussions around the upcoming sandboxing requirement for all the Mac App Store published applications.

There were several publications on the subject with sometimes very elaborate discussion:

• MacRumors
• Slashdot
• Daring Fireball
• Wil Shipley

These articles lead me to wondering:

• Apple is going to enforce sandboxing on third-party applications, but what about Apple's own applications ?
• Sandboxing is said to be a work in progress; the current entitlement keys are sparse and most of the time, developers relies on temporary exceptions to keep their application fully functional. Is there anything in Apple's applications that give a clue of possible entitlement keys ?

So, I decided to take my Terminal and play with the codesign tool. This tool is very useful because if can sign binaries (obviously), but it can also print what is contained in the signature (certificate chain, requirements, entitlements). So I ran it on my Application folder.

cd /Applications
find . -type d -name "*.app" -exec echo {} \; -exec codesign -d --entitlements - {} \;

Here are the applications that contain entitlements (as on 2011-11-06). I have indicated if they mandate the use of sandbox:

• Address Book
• App Store
• FaceTime
• Font Book
• Preview (SANDBOXED)
• TextEdit (SANDBOXED)
• Activity Monitor
• Boot Camp Assistant
• RAID Utility
• iCal
• PhotoStreamAgent (in iPhoto)
• iTunes

Here are the key points:

• All the Apple applications are signed
• Only a few of them contain entitlements
• Only two of them are sandboxed

Digging further into the entitlements, I found:

• Preview is actually using a temporary entitlement key for global Mach lookup. So don't be shy using them into your applications !
• A bunch of private entitlement keys: they may be migrated to public entitlement keys as they seems generic.

And finally, here are the private entitlement keys I found:

• com.apple.private.aps-connection-initiate: it seems related to iCloud, as applications like Address Book, FaceTime, iCal, iTunes and iPhoto (PhotoStreamAgent) have this one.
• com.apple.private.dark-wake-push: a key to wake up the computer ???
• com.apple.private.AuthorizationServices: widely used, it seems a good candidate for a future entitlement key.

I hope that by March 2012, Apple would have solved all the details about sandboxing. It would be nice to see a set of versatile entitlement that could protect the end-user and let the developer be inventive.

The upcoming version of Monobjc 4.0, will be able to run on Mac OS X 10.5, 10.6 and 10.7 operating systems under both i386 and x86_64 architectures. For a complete coverage of this platforms and architectures, the goal is to have these three platforms readily available so non-regression and deployment testing occurs almost seamlessly.

Thanks to Parallels Desktop, I was able to quickly setup two virtual machines running respectively Mac OS X 10.5 and 10.6, on top of a Mac OS X 10.7 system. Then I setp up a Jenkins based continuous integration system driving all the platforms; non-regression testing can now be run on the three platforms easily.

If you ever wanted to try (or even use) Mono 64 bits on Mac OS X, I have created a small project on GitHub called Mono-Sixty-Four. This is a simple scrip that creates a minimal 64 bits Mono runtime and merges it with an existing Universal 32 bits Mono runtime. At the end, you get a Universal 32/64 bits Mono runtime.

For the moment, only the Mono runtime supports 64 bits. Additional libraries (GTK, SQLite, etc) ARE not supported.

Many people want to package their .NET application for Mac OS X. And above all, they want the experience to be painless, which means that they want to ship an application that runs, whether Mono is installed or not.

The process of packaging a .NET application for Mac OS X basically follows 4 steps:

• Getting .NET dependencies of the .NET executable
• Generating a native loader that will embed all the .NET assemblies (.NET executable and .NET dependencies)
• Getting native dependencies of the native executable
• Relocating all the stuff so library loading goes well

The process can be even more complicated if you are using reflection, dynamically discovered library and so on. So let's keep thing simple.

Getting .NET dependencies

This is the easy part. You just have to find recursively all the .NET dependencies of the .NET executable. As every .NET assembly contains its references, it is trivial.

Generating a native loader

The native loader generation is simplified by the fact that Mono allows .NET assemblies to be loaded from embedded binary streams. So for every .NET assembly, we generate a binary array and use the magical functions of Mono. If there are configuration files to embed, the process is the same.

Getting native dependencies

Once the native loader is compiled, the otool command can give us all the native dependencies. So we gather all the native library needed to run our application. But on Mac OS X, the dynamic loading is based on paths recorded in each native library. This is the point of the next step.

Relocating all the stuff

This is the tougher part of the packaging. Now that you have all the native dependencies, you must be sure that you only have unique dependencies. Why, because we you gather dependencies, you can find either specific version of a library or compatibility version of a library. Failing to make these reference unique can lead to unexpected behavior (mostly cryptic crashes). That where the otool command is useful as the first line always contains the specific version of a library, even if run against a compatibility version symbolic link. Then the install_name is used to change absolute path to relative path containing the macro @executable_path.

Packaging made easy

All this steps can be tedious and error prone. That's why, in the Monobjc, the packaging is done by a NAnt task: <mkbundle/> (you can find its options on this page). This task can handle most of the need for .NET application packaging in a truly simple way. And as a bonus, this task is not linked to the Monobjc bridge, so you can use it even if you don't use the Monobjc bridge.

Monobjc is more than one year old, and the time has come to go beyond the Monobjc bridge. In order to develop the .NET programming on Mac OS X, a bridge is not enough. A whole development ecosystem is needed, so any new developer will have all the necessary tools to leverage the power of .NET on Mac OS X. I have identified several tools needed when developing applications:

• IDE: An IDE is great as it speeds up the edition on multiple document and centralized the application development (code writing, compilation and packaging). Unfortunatly, an IDE is a very complex machinery. Identified solutions: fork SharpDevelop or MonoDevelop.
• Reflector: A tool like Red Gate Reflector is useful when dealing with assemblies. The though part is to write the IL reverse-engineering engine. Identified solution: a Reflector clone based on Mono Cecil.
• Obfuscator: When distributing applications, obfuscation is an additional mesaure to protect your investment. Identified solution: an obfuscation tool based on Mono Cecil.

The ecosystem can also be completed by libraries either based on Mac OS X framework (Sparkle, Growl, ...) or existing .NET libraries. Stay tuned as now, the goals for Monobjc are clear.