They're not going to change anything, and it doesn't even make sense to suggest that they should. /usr/bin/git isn't a Git binary. It's a tool that is equivalent to running `xcrun git "$@"` (which runs git from inside your default Xcode / Command Line Tools installation). So even if you could replace /usr/bin/git, you'd still have a vulnerable Git binary on your system, since you won't have replaced the tool that /usr/bin/git was actually executing.
So basically, you can update the executable yourself?
See, this makes very little sense. SIP has been designed to prevent malware authors updating executables in system directories. But they use a tool that locates and executes an executable in a directory that can be updated. So what, pray tell, was the point of SIP when their own people poke huge holes like this in their supposedly immutable discretionary access control system?
If I'm a malware author who somehow gains access to root, I just locate where git is actually located and I install my own compromised version. Sure, other executables haven't been compromised which is a good thing... but it seems pointless installing executables like git that aren't directly essential to the running of OS X in this system folder in the first place!
I recognise that I may be missing something, but for the life of me I'm struggling to see what this might be. If someone knows, please inform me rather than voting me down, I'm interested in understanding the logic behind all of this!
`git` is not a system-critical component. Nothing on the system relies on it working (after all, it doesn't even work at all until you install Xcode). It's really only protected because all of /usr/bin is protected.
Another way to look at it is there's not much difference between replacing the binary that /usr/bin/git executes and adding a compromised `git` binary somewhere in the user's PATH, since the user will invoke your malicious tool either way the next time they run `git`. The former only serves to affect scripts that hard-code /usr/bin/git (except that's not very common since it's not at that path on all systems, and hard-coding that means the user can't provide their own version of git if they want to).
Edit: All that said, Xcode and all of its embedded components are code-signed, and it's entirely possible that /usr/bin/git requires the actual git binary to be codesigned by Apple. The only way to test that is for me to intentionally break my Xcode install and I'm not going to do that since I actually need it to work.
Edit 2: Also, why the heck would you try to compromise /usr/bin/git anyway? If you're in a position to do that, you're already in a position to execute whatever code it is you want, so waiting until the user executes `git` to do it isn't very useful.
So what's the point of stopping root from updating git in /usr/bin/git in the first place? Wouldn't it be better for Apple to have put non-system critical executables in a different directory which is writable by root and added this to $PATH?
• This means Apple inventing a brand new system-level nobody-but-Apple-should-really-be-touching-this folder for storing the handful of developer tools shims, for which there is no -nix precedent and so they'd have to make up something new.
• This alters the default PATH, which will probably break a lot of stuff because it's not all that uncommon to reset PATH back to the default of "/usr/bin:/bin" or to the fairly common "/usr/local/bin:/usr/bin:/bin".
• There's no benefit at all to doing this. Why would you even bother separating out these tools? The user shouldn't be modifying them anyway, so why should Apple go out of its way and potentially break a lot of software simply so the user can in fact replace the shim that executes the Xcode-bundled version of git? Not only is there no benefit, but there is a lot of potential harm in doing this, because once the user replaces that shim there's no way to get it back. It is part of the system, even though it's not system-critical, and if you replace it there's no way to fix it short of reinstalling the entire OS.