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.

• blog post

The final fruit of my endeavour is a program called git-password, binary available here. It was written in Xcode 4 and the source is available here.

To use the program first you need to download it and make it executable.

    curl -L http://bit.ly/git-password > ~/git-password
    chmod +x ~/git-password

And now depending on your version of git you have 2 different ways of making git use the program.

Git 1.7.3 and above:

    git config --global core.askpass ~/git-password

Git 1.7.2 and below:

    echo export GIT_ASKPASS="$HOME/git-password" >> .bash_profile

And now just go and clone any https repository or update the url of your remotes.

I started writing this program using ruby and some system calls to the security command line tool. But to store a password in your keychain using this tool you have to pass it as an argument to security which means anyone on the system can see this if they know were to look. This quickly ruled out using the security tool so I had to look at using the keychain api natively.

My next step was to search for a gem that wrapped the C api for me so I don’t have to get my hand dirty in C. I found the mac-keychain gem and later heard about zenspider’s gem osx_keychain. Using native C functions to add the password prevents it from being available in plaintext to other processes which fixes that problem. But I quickly found another problem.

Each OS X Keychain item has a list of authorized applications that can read the password from the item without the user being prompted.

When you add an item to the keychain unless you otherwise specify, the current application running is implicitly the only authorized application. This makes sense because you store passwords to be able to recover their plaintext later (otherwise you should be using a key derivation function like bcrypt or scrypt).

The problem is that when you call the native C functions from inside ruby, ruby is the application that is running (your code is just a script that Keychain is unaware of). So this means that any ruby script can freely retrieve the passwords stored by other ruby scripts (and thus enable a rarely large security flaw with your program) without the user being prompted to give permission.

So I had to scrap the idea of using ruby and write my own C program to do it. This would prevent anyone from running code on the computer and being able to freely retrieve passwords stored by my application (along with the application names, a signature is stored so if someone wrote their own application with the same name, it would still prompt the user for access).

The next step was to confirm that git was the one that was calling the program so someone cannot do git-password "Password: " inside of a git repository and have the program give the password up. I took a while but I finally found some sample code that shows how to get the list of processes on OS X and that combined with getppid allows me to check that git was the program that started us (technically it’s git-remote-https).