5 ms·

I'd like to point out, however, that installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, y

by joushou 10y ago

I'd like to point out, however, that installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH. Tricking you into using the old version would require execution rights on the machine. You can also remove the /usr/bin/* binaries if you boot the machine without the system integrity features. You can boot back to normal after the modification. It is inconvenient that these dev tools are not updated frequently (bash, zsh, and many other command line tools are terribly out of date), but it is not terribly difficult to install a fresh version in parallel.

falcolas 10y ago
> Tricking you into using the old version would require execution rights on the machine Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user). Re-ordering `/usr/bin` and `/usr/local/bin` in $PATH isn't that hard.
- coredog64 10y ago
  I would argue it's not even that difficult. In the README.md, put some kind of note that there's a bug in the current version of git (and maybe point to some random Google group posting) and mention that on OS X it's better to use the XCode version.
  - joushou 10y ago
    This is indeed an issue. I would like to think that a person capable of using git would have enough of a critical mindset not to do what random people on the internet tell you to do, but... StackOverflow kinda proves the opposite. I don't think you'll ever be able to help people that follow internet advice blindly, for these people, it might be better not to bundle anything at all.
- joushou 10y ago
  With the ability to modify .bashrc, you have execution right to the machine. If not before, to modify the file, then after, because you modified a shell script that is automatically run all the time. Thr machine is already pwned, and one privilege escalation bug away from being completely lost. With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. It is hardly related to the issue with git.
  - pdonis 10y ago
    > With the ability to modify .bashrc, you have execution right to the machine. You have the user's execution rights only; you don't have root access. > Thr machine is already pwned, and one privilege escalation bug away from being completely lost. This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge. > With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. And the user can unmask them just as easily. It's not at all the same as having root access.
    - joushou 10y ago
      > You have the user's execution rights only; you don't have root access. That is also what I said - code execution. Like the git RCE gives you. But, it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? With .bashrc, it doesn't matter how new your git is, there's no reason to exploit it. Also, privilege escalation bugs. > This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge. Exactly my point. If the .bashrc has been modified in an evil way, as you suggested, you're screwed because someone is executing code as your user, which is usually exactly what they need. Add one privilege escalation, and they can do whatever they want, but that's not really necessary, depending on what they want to do. In essence, if I can write to a file of my liking on your machine as your user, then I have code execution rights as your user (potentially with a time delay, depending on what I tamper with). > And the user can unmask them just as easily. It's not at all the same as having root access. Exactly, like installing a different version of git with homebrew and masking the old one. Also, privilege escalation bugs. I think you're forgetting how common they are. A decent set of privilege escalation bugs is part of any decent hackers toolkit. If someone modifies .bashrc, as you initially suggested ("Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user)"), then the git RCE is redundant, as you already have obtained code execution on the machine.
satysin 10y ago
Does OS X have something like update-alternatives on Debian?
- joushou 10y ago
  No, the dev tool binaries are magic binaries that check if the "Command Line Tools" package is installed, and if not, asks you if you want to download it. They're protected by System Integrity Protection, so you have to temporarily boot with that disabled to remove or modify them. I think it's a fairly common measure to download a lot of what OS X comes with over homebrew, simply because OS X's versions tend to be annoyingly outdated (Like bash 3.2.57, vs. 4.3.42 from homebrew).
  - satysin 10y ago
    That sounds annoying.
    - joushou 10y ago
      A little, but you have enough to get started. Rather an old bash than no bash. First task on OS X is usually to use the bundled curl and ruby to get homebrew. :)
      - satysin 10y ago
        Will be interesting when Windows comes (well via an update) with a later version of bash than OS X!
        joushou 10y ago
        Hah, and that might not even take that long at the current rate! But we still got a better terminal emulator by default over here! Terminal.app is a pretty darn good terminal emulator, although iTerm2.app is better. That is actually one of the things I like about OS X - I have not found a terminal emulator for Linux (and certainly not for Windows) that compares with iTerm2. Not in speed, nor in interface.
pdonis 10y ago
> installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH Sure, but the fact remains that OS X deliberately hides things from you, and you have no way of knowing that you've found all the hidden things. And for a developer, I think that's unacceptable. I want full root access to my development machine, not a dumbed down version of "root" that doesn't let me mess with certain things. This is one of the key reasons why I will not use a Mac as a development machine.
- joushou 10y ago
  It doesn't hide anything related to git. The binary in /usr/bin is there to shat xcode-select works and points to /Application/Xcode.app/Contents/.../bin/git. It's not hidden, it's merely a convenience so that you can actually get git, and stay at least a little up to date. There's nothing hidden about it, and installing new, modifying your path, whatever is done just like you would on any other machine. The binaries are protected by "rootless mode"/System Integrity Protection, but you can disable this and get full root access to your development machine. Just run "csrutil disable" from recovery mode (It wouldn't really help if you could disable it from a running system). The only locked down things on OS X are proprietary GUI stuff, such as windowserver or some menubar API's. Regular operation is not locked down.
  - jamessb 10y ago
    It doesn't hide anything related to git The link between /usr/bin/git and /Application/Xcode.app/Contents/.../bin/git is hidden. I don't know how you would discover this: ls indicates /usr/bin/git is a regular file rather than a symlink; stat -f "%i" says the two files have different inodes, so they're not hardlinked. What is the nature of the link, and how would you find this if you didn't already know?
    - joushou 10y ago
      man xcode-select - It's right there in the manpage. /usr/bin/git is a "toolshim" that effectively calls "xcrun git" (it actually calls xcselect_invoke_xcrun, from /usr/lib/libxcselect.dylib, if you really want the details - this can be found by inspecting the binary). xcode-select's manpage tells you that these shims call the respective binary in the active developer directory, whereas xcrun's manpage describes its capabilities in more detail. It took about 3 minutes to figure out.
fishywang 10y ago
Imagine that you are a corp IT and managing a fleet of developers with Macs. You can push a newer version of git to them, and you can even change their default PATH so that the version of git you pushed are before the git comes with Apple. But you still cannot remove the one comes with Apple, and you cannot prevent it from being used.
- joushou 10y ago
  Well, you can, but it's inconvenient and requires manual intervention with each machine. I would argue, though, that if you have developers that intentionally circumvent the version of git you provided them with, despite being told that it's there for security reasons (and is newer, better, flashier and all), then you're dealing with people that can't be helped, and shit will happen regardless. I'm not arguing that it's okay that Apple bundles an affected version of git, but if they start undoing what you did to protect them, I don't think they can be helped. I'm a bit pessimistic in this sense, but I keep getting surprised by the kind of crap that makes their way onto peoples machines, sometimes people that really should know better.
  - fishywang 10y ago
    That might be unintended. For example some software might stupidly hardcoded /usr/bin/git instead of using the default one from PATH, or the PATH is actually quite tricky on Mac (bashrc controls what comes by default from bash, but the PATH in GUI is controlled by other files).
    - joushou 10y ago
      As, yeah, stupid applications is hard to guard against, but stupid applications might/will have their own share of code execution bugs, which you also have to control. Everything sucks. As for the environment, that's the same for any UNIX, though. .bashrc is run only if you start bash. Getting an ubuntu dist. to set up your environment variables in GUI applications certainly won't be fixed with a .bashrc. It might inherit /etc/profile, if you're lucky. For OS X, launchd handles the environment by simply being the one responsible for starting the applications that you inherit your environment from (such as Finder, Dock and Spotlight), and .bashrc is just a file that bash executes itself that might set additional environment variables. This is not unlike a Linux setup, where you only inherit environment variables written in .bashrc if you started the application from bash. (OS X does have a path management system for shells in the form of path-helper and /etc/path.d/, but that's run through the profile, which won't affect GUI applications.) I'm not really trying to defend OS X here, other than pointing out that if you cut out the proprietary GUI stuff, it's basically just your run-of-the-mill custom UNIX dist. As a long time Linux user (I use a Mac as laptop, because screw trying to get Linux working perfectly on a laptop), I find everything to be an equal pain in the ass to deal with. systemd or launchd, X11 or windowserver, Finder, Nautilus, Konqueror or even Windows Explorer - They all suck. Pick your poison.

by joushou 10y ago

falcolas 10y ago

> Tricking you into using the old version would require execution rights on the machine Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user). Re-ordering `/usr/bin` and `/usr/local/bin` in $PATH isn't that hard.

coredog64 10y ago
I would argue it's not even that difficult. In the README.md, put some kind of note that there's a bug in the current version of git (and maybe point to some random Google group posting) and mention that on OS X it's better to use the XCode version.
- joushou 10y ago
  This is indeed an issue. I would like to think that a person capable of using git would have enough of a critical mindset not to do what random people on the internet tell you to do, but... StackOverflow kinda proves the opposite. I don't think you'll ever be able to help people that follow internet advice blindly, for these people, it might be better not to bundle anything at all.
joushou 10y ago
With the ability to modify .bashrc, you have execution right to the machine. If not before, to modify the file, then after, because you modified a shell script that is automatically run all the time. Thr machine is already pwned, and one privilege escalation bug away from being completely lost. With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. It is hardly related to the issue with git.
- pdonis 10y ago
  > With the ability to modify .bashrc, you have execution right to the machine. You have the user's execution rights only; you don't have root access. > Thr machine is already pwned, and one privilege escalation bug away from being completely lost. This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge. > With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. And the user can unmask them just as easily. It's not at all the same as having root access.
  - joushou 10y ago
    > You have the user's execution rights only; you don't have root access. That is also what I said - code execution. Like the git RCE gives you. But, it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? With .bashrc, it doesn't matter how new your git is, there's no reason to exploit it. Also, privilege escalation bugs. > This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge. Exactly my point. If the .bashrc has been modified in an evil way, as you suggested, you're screwed because someone is executing code as your user, which is usually exactly what they need. Add one privilege escalation, and they can do whatever they want, but that's not really necessary, depending on what they want to do. In essence, if I can write to a file of my liking on your machine as your user, then I have code execution rights as your user (potentially with a time delay, depending on what I tamper with). > And the user can unmask them just as easily. It's not at all the same as having root access. Exactly, like installing a different version of git with homebrew and masking the old one. Also, privilege escalation bugs. I think you're forgetting how common they are. A decent set of privilege escalation bugs is part of any decent hackers toolkit. If someone modifies .bashrc, as you initially suggested ("Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user)"), then the git RCE is redundant, as you already have obtained code execution on the machine.

satysin 10y ago

Does OS X have something like update-alternatives on Debian?

joushou 10y ago
No, the dev tool binaries are magic binaries that check if the "Command Line Tools" package is installed, and if not, asks you if you want to download it. They're protected by System Integrity Protection, so you have to temporarily boot with that disabled to remove or modify them. I think it's a fairly common measure to download a lot of what OS X comes with over homebrew, simply because OS X's versions tend to be annoyingly outdated (Like bash 3.2.57, vs. 4.3.42 from homebrew).
- satysin 10y ago
  That sounds annoying.
  - joushou 10y ago
    A little, but you have enough to get started. Rather an old bash than no bash. First task on OS X is usually to use the bundled curl and ruby to get homebrew. :)
    - satysin 10y ago
      Will be interesting when Windows comes (well via an update) with a later version of bash than OS X!
      - joushou 10y ago
        Hah, and that might not even take that long at the current rate! But we still got a better terminal emulator by default over here! Terminal.app is a pretty darn good terminal emulator, although iTerm2.app is better. That is actually one of the things I like about OS X - I have not found a terminal emulator for Linux (and certainly not for Windows) that compares with iTerm2. Not in speed, nor in interface.

pdonis 10y ago

> installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH Sure, but the fact remains that OS X deliberately hides things from you, and you have no way of knowing that you've found all the hidden things. And for a developer, I think that's unacceptable. I want full root access to my development machine, not a dumbed down version of "root" that doesn't let me mess with certain things. This is one of the key reasons why I will not use a Mac as a development machine.

joushou 10y ago
It doesn't hide anything related to git. The binary in /usr/bin is there to shat xcode-select works and points to /Application/Xcode.app/Contents/.../bin/git. It's not hidden, it's merely a convenience so that you can actually get git, and stay at least a little up to date. There's nothing hidden about it, and installing new, modifying your path, whatever is done just like you would on any other machine. The binaries are protected by "rootless mode"/System Integrity Protection, but you can disable this and get full root access to your development machine. Just run "csrutil disable" from recovery mode (It wouldn't really help if you could disable it from a running system). The only locked down things on OS X are proprietary GUI stuff, such as windowserver or some menubar API's. Regular operation is not locked down.
- jamessb 10y ago
  It doesn't hide anything related to git The link between /usr/bin/git and /Application/Xcode.app/Contents/.../bin/git is hidden. I don't know how you would discover this: ls indicates /usr/bin/git is a regular file rather than a symlink; stat -f "%i" says the two files have different inodes, so they're not hardlinked. What is the nature of the link, and how would you find this if you didn't already know?
  - joushou 10y ago
    man xcode-select - It's right there in the manpage. /usr/bin/git is a "toolshim" that effectively calls "xcrun git" (it actually calls xcselect_invoke_xcrun, from /usr/lib/libxcselect.dylib, if you really want the details - this can be found by inspecting the binary). xcode-select's manpage tells you that these shims call the respective binary in the active developer directory, whereas xcrun's manpage describes its capabilities in more detail. It took about 3 minutes to figure out.

fishywang 10y ago

Imagine that you are a corp IT and managing a fleet of developers with Macs. You can push a newer version of git to them, and you can even change their default PATH so that the version of git you pushed are before the git comes with Apple. But you still cannot remove the one comes with Apple, and you cannot prevent it from being used.

joushou 10y ago
Well, you can, but it's inconvenient and requires manual intervention with each machine. I would argue, though, that if you have developers that intentionally circumvent the version of git you provided them with, despite being told that it's there for security reasons (and is newer, better, flashier and all), then you're dealing with people that can't be helped, and shit will happen regardless. I'm not arguing that it's okay that Apple bundles an affected version of git, but if they start undoing what you did to protect them, I don't think they can be helped. I'm a bit pessimistic in this sense, but I keep getting surprised by the kind of crap that makes their way onto peoples machines, sometimes people that really should know better.
- fishywang 10y ago
  That might be unintended. For example some software might stupidly hardcoded /usr/bin/git instead of using the default one from PATH, or the PATH is actually quite tricky on Mac (bashrc controls what comes by default from bash, but the PATH in GUI is controlled by other files).
  - joushou 10y ago
    As, yeah, stupid applications is hard to guard against, but stupid applications might/will have their own share of code execution bugs, which you also have to control. Everything sucks. As for the environment, that's the same for any UNIX, though. .bashrc is run only if you start bash. Getting an ubuntu dist. to set up your environment variables in GUI applications certainly won't be fixed with a .bashrc. It might inherit /etc/profile, if you're lucky. For OS X, launchd handles the environment by simply being the one responsible for starting the applications that you inherit your environment from (such as Finder, Dock and Spotlight), and .bashrc is just a file that bash executes itself that might set additional environment variables. This is not unlike a Linux setup, where you only inherit environment variables written in .bashrc if you started the application from bash. (OS X does have a path management system for shells in the form of path-helper and /etc/path.d/, but that's run through the profile, which won't affect GUI applications.) I'm not really trying to defend OS X here, other than pointing out that if you cut out the proprietary GUI stuff, it's basically just your run-of-the-mill custom UNIX dist. As a long time Linux user (I use a Mac as laptop, because screw trying to get Linux working perfectly on a laptop), I find everything to be an equal pain in the ass to deal with. systemd or launchd, X11 or windowserver, Finder, Nautilus, Konqueror or even Windows Explorer - They all suck. Pick your poison.