So yesterday I wrote a little Objective C tool that behaves like
rm but instead sends the files or directories to your Trash using Finder. The code is available at samuelkadolph/trash. You can clone that repo and run
make install or if you have homebrew you can run this:
brew install https://raw.github.com/samuelkadolph/homebrew/add_trash_formula/Library/Formula/trash.rb
So I've been playing around with Lion sandboxing and using entitlements for a Cocoa app. (In case you didn't hear, all apps submitted to the App Store have to be sandboxed come this November.) The first thing you may notice when you enable sandboxing for your app in Xcode is that it turns on code signing. It has to do this because entitlements don't work unless you sign your code. Once code signing is turned on and you try to compile you may get an error:
[BEROR]Code Sign error: The identity '3rd Party Mac Developer Application' doesn't match any valid certificate/private key pair in the default keychain
This because by default Xcode will try to sign your code with an identity in your keychain that starts with
3rd Party Mac Developer Application. To be able to submit apps to the App Store you have to get a certificate from Apple so this is a sane default but I wasn't signed up of the Mac Developer Program. I was however signed up for the iOS Developer Program so to fix the error for now I changed the
Code Signing Identity build setting to
iPhone Developer and away I went.
Fast forward a few days after I had signed up for the Mac Developer Program and I got my certificate. So I got rid of my change
Code Signing Identity and restored the default. But I soon ran into a problem, my application now crashed while starting up no matter what I changed with a
EXC_BAD_INSTRUCTION error in some random Apple code.
I quickly localized the problems to having entitlements on but the non-existance of any documentation on debugging sandbox errors from Apple I was frustrated. So I fired up my application without Xcode so there would be a error trace I could view in Console. This was a great idea because I was actually able to see what was the error was.
What immediately jumped out at me was
Code identity not in ACL for container ~/Library/Containers/org.samuelkadolph.Foo/Data
and I suddenly remembered something I read in the sandbox documentation. By default in the Lion sandbox, you can only access files in a special directory under
~/Library/Containers which is named after the bundle identifier for your app. And it's protected to prevent someone from accessing the data in there with a fake app. This protection is achieved by using info from the app which was signed by your code signing identity to confirm a genuine app from a fake. So when I changed the keychain identity used to sign the code I was creating a fake app and trying to access the data.
The solution was simple after determining that was the problem. Just delete the container for your app (and only your app, every other sandboxed app has a container too and may store data in them). In my case it was
rm -rf ~/Library/Containers/org.samuelkadolph.Foo.
It's unfortunate that Xcode isn't more helpful with this error and unfortunate that OS X will kill (with SIGKILL too) an application instead of using some error handling in the app itself. I hope this post helps you if you ever run into this problem.
After playing around with using TrueCrypt and syncing the volume over Dropbox I was disappointed to discover that it doesn't let you mount the volume by double clicking on the file. You have to open TrueCrypt, select the file and then type in your password.
To further expand my knowledge of OS X application bundles I set out to write an application that associated with the
.tc file extension and when you opened a
.tc file it would prompt your for your password and once you are done and eject the disk, automatically dismount the TrueCrypt volume.
The fruit of my labour is available in this GitHub repository and you can download the application here. Once you have copied the application to your
Applications directory, it will associate with any
*.tc file. You must add this extension to any of your TrueCrypt volumes because (unfortunately) TrueCrypt does not do this for you automatically.
One annoying change in Lion was the disabling of key repeating because it has been replaced with an accent selection menu. It is easy to change back to the standard functionality of holding down a key.
Run this in your terminal and log out and in (or restart).
defaults write -g ApplePressAndHoldEnabled -bool false
Back at the start of April I wrote mysql2 ruby gem and Mac OS X: image not found to deal with the extremely relative path to
libmysqlclient.16.dylib. I had said I would prefer not putting
/usr/lib but I couldn't find a dylib path that ruby uses. That is until today when I decided to try again.
RbConfig::CONFIG which is the directory where ruby can load dylib files from.
libexecdir=$(ruby -rrbconfig -e 'puts RbConfig::CONFIG["libexecdir"]')
sudo mkdir -p $libexecdir
sudo ln -s /usr/local/mysql/lib/libmysqlclient.16.dylib $libexecdir
Now ruby can load
libmysqlclient.16.dylib without putting it in
I forgot to mention it in the first post but if your ruby wants
libmysqlclient.18.dylib, just replace the 16 with 18. Same with any other number.
If you are using the mysql2 ruby gem on Mac OS X you may have run into this problem before.
> require 'mysql2'
LoadError: dlopen(mysql2-0.2.7/lib/mysql2/mysql2.bundle, 9):
Library not loaded: libmysqlclient.16.dylib
Referenced from: mysql2-0.2.7/lib/mysql2/mysql2.bundle
Reason: image not found - mysql2-0.2.7/lib/mysql2/mysql2.bundle
So far the only solution I have found online is to use
install_name_tool to update the (extremely) relative
libmysqlclient.16.dylib reference to be absolute (usually to
While this solves the problem, it only works until you reinstall the mysql2 gem or install a newer version and then you have to do it again. To permanently solve it you need to create a symlink of
/usr/lib so that it can be found with that default relative path.
Ideally you wouldn't put it in
/usr/lib but I haven't be able to find a path inside of ruby that will let you load the
sudo ln -s /usr/local/mysql/lib/libmysqlclient.16.dylib /usr/lib
Enter your password and then you can use the
mysql2 gem without needing to edit the compiled bundle afterwards.
Around this time last year git added a "smart" HTTP transport that is faster than the old HTTP transport (and in some cases faster than SSH too). And a few months later GitHub added support for this new HTTP transport and made it the default selected url for repositories (that you aren't a contributor for).
There aren't any major advantages using https over ssh to access your GitHub repositories, it's just more simple to use your username/password instead of adding your ssh key. The only other advantages is that it's easier to set up HTTP proxy for git (
git config --global http.proxy proxy:8080 vs ssh config) and being able to use more than one GitHub account (which you shouldn't since anyone can add you as a contributor to a project).
One major disadvantage is that it asks you for your username/password each time you interact with your remote repository (clone, pull, push, etc). To solve this, I decided to write a program that stores your username and/or password in your keychain so git will ask once for you username/password and retrieve it later so you don't have to type it again. If you only want the program, skip to it.
Continue reading "Store your git https passwords in your OS X Keychain"