But I quickly found another problem.Įach OS X Keychain item has a list of authorized applications that can read the password from the item without the user being prompted. Using native C functions to add the password prevents it from being available in plaintext to other processes which fixes that problem. I found the mac-keychain gem and later heard about zenspider's gem osx_keychain. 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.
This quickly ruled out using the security tool so I had to look at using the keychain api natively.
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. I started writing this program using ruby and some system calls to the security command line tool. If you only want the program, skip to it. 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. One major disadvantage is that it asks you for your username/password each time you interact with your remote repository (clone, pull, push, etc). 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). 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. 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). 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).
0 kommentar(er)
