Abstract (what the kids these days call "tl;dr"): Attempting to prevent malicious code, executing under your account, from reading your MacOS Keychain passwords is doomed to failure and will result in pointless UX inconvenience. Solution: Don't execute malicious code.
I'm greatly appreciative of Mr. Kadolph's git-password helper program. Requiring people to repeatedly enter their password is a wretched idea. Aside from the horrible user experience, it discourages the use of high-random passwords (e.g.,
dd if=/dev/urandom bs=16 count=1 | openssl base64). LastPass's excellent password generator uses approximately this technique, as do I personally. If actually typing my github password is a rare event, and the password isn't something I can memorize, then the odds of my being phished or it getting spied on by a keystroke logger are markedly reduced.
In the explanation for why he chose to implement it in C, he rightly points out that using native C bindings from Ruby would result in any Ruby script being able to recover the password without triggering the Allow/Deny dialog box. However, I take issue with assertion that the native C helper binary is any safer.
Below is a proof-of-concept on how you'd recovery it. git-password-bypass.c isn't that magical - it's just a cribbing of his is_git_calling_us() function with some extra code. The thing to note is that the magic data structure kinfo_proc.p_comm simply contains the filename that the parent process was exec()'d from. A simple
cp /bin/bash ./git-remote-https will result in a copy of bash with a p_comm name of "git-remote-https". Based on testing, exec()'ing a symlink will yield the name of the target file, but a hardlink will have the same masquerading property as the cp.
This isn't the only immediate bypass. One can also imagine a malicious script (ruby, bash, or otherwise) using gdb or another debugger to invoke the legit-for-realzies git-remote-https binary. The attacker can then simply step through line-by-line until the password has been read back from git-password, and then proceed to access your precious bodily fluids^W^Wrepos.
While Apple does provide a mechanism for processes to opt-out of debugger inspection (
man ptrace and see PT_DENY_ATTACH), this unfortunately doesn't provide a lot of defense. See http://www.scsc.no/blog/2011/07-28-running-itunes-in-a-debugger-gdb.html for an example of how to bypass iTunes's attempt to wrap a Harry Potter-style Cloak of Invisibility about itself.
In my experience, once an attacker has the ability to execute arbitrary code on a *nix host, it is exceptionally difficult to prevent it from (in the words of my government's FAA) tampering with, disabling, or destroying other processes running as the same user. If your threat model is that you distrust "any ruby script" on your host, then the solution is to be very picky about which ruby scripts you use.
EDIT: This isn't to say I think Keychain is worthless - far from it. When it comes to protecting against backup leakage or arbitrary file traversal bugs that are short of arbitrary code execution, Keychain is a wonderful solution. I desperately wish that Microsoft's DPAPI had half the tooling around it. And don't get me started on the kwallet/Gnome Keyring pile of stupid.