Hacker News new | ask | show | jobs
by eridius 3697 days ago
What you've written is an extremely long-winded and incredibly misguided and wrong post, I don't even know how to address all of the problems here, so here's a quick summary:

• Xcode is a self-contained app bundle, it does not install components across the system, which would be required for your scheme. This is intentional for several reasons.

• Having 2 copies of Xcode installed at once is explicitly supported. This requires that Xcode not be installing components across the system or it they would interfere with each other.

• Your description of xcode-select is overly-convoluted. In practice it's really very simple. xcode-select sets the default Xcode installation used for xcrun and the shims. You can override this selection on a per-invocation basis by setting the DEVELOPER_DIR env variable instead. If you don't have the env variable set, xcode-select is roughly equivalent to replacing all of the shims with symlinks that point into the selected directory. And you haven't explained why any of this is supposed to increase the "attack surface".

• You keep claiming that this defeats the purpose of SIP, which makes no sense at all. I can't even figure your logic for claiming it defeats SIP, which makes me wonder if maybe you're just trying to spread FUD.

• I absolutely do know how Linux distros suggest packages, please don't try to tell me that I don't.

• Using bash v4 is not more sensible than installing a shim, because, as I've explained at great length, is required for reasons other than just suggesting the installation of Command Line Tools. You keep ignoring all of the reasons why this is required for current functionality and are focusing on the single aspect, of suggesting the installation of Command Line Tools, that could conceivably be done a different way.

• Besides, saying "use bash v4" is not a solution anyway, because many people do in fact switch their default shell, at which point they'd lose the instructions on how to install the command-line tools.

I'd really rather you don't give me another long-winded reply that boils down to you saying "I don't understand the point of SIP or how it works, or how Xcode's self-contained app installation works".

1 comments

> • Xcode is a self-contained app bundle, it does not install components across the system, which would be required for your scheme. This is intentional for several reasons.

A self contained app bundle that does not install components across the system and requires access to common executables that redirect access to utilities shared amongst the app bundles.

Doesn't that tend to break the self-contained nature of the packages?

If I was to setup two completely seperate Xcode environments that I needed to run at the one time I think I'd probably investigate a chroot jail.

> • Having 2 copies of Xcode installed at once is explicitly supported. This requires that Xcode not be installing components across the system or it they would interfere with each other.

I'm not following. How does having shims for git prevent this?

• Your description of xcode-select is overly-convoluted. In practice it's really very simple. xcode-select sets the default Xcode installation used for xcrun and the shims. You can override this selection on a per-invocation basis by setting the DEVELOPER_DIR env variable instead. If you don't have the env variable set, xcode-select is roughly equivalent to replacing all of the shims with symlinks that point into the selected directory. And you haven't explained why any of this is supposed to increase the "attack surface".

I thought this was rather obvious... Apple don't want people to symlink to other applications from /usr/bin just by exporting an environment variable.

  630188s-iMac:~ 5K$ mkdir -p ~/xcsl/usr/bin
  630188s-iMac:~ 5K$ echo '#!/bin/sh' > ~/xcsl/usr/bin/xcrun
  630188s-iMac:~ 5K$ echo 'echo "Hello world!"' >> ~/xcsl/usr/bin/xcrun
  630188s-iMac:~ 5K$ chmod a+x ~/xcls/usr/bin/xcrun
  630188s-iMac:~ 5K$ export DEVELOPER_DIR=~/xcsl/
  630188s-iMac:~ 5K$ git
  Hello world!
Notice something? No sudo needed.

> • You keep claiming that this defeats the purpose of SIP, which makes no sense at all. I can't even figure your logic for claiming it defeats SIP, which makes me wonder if maybe you're just trying to spread FUD.

See above.

>• I absolutely do know how Linux distros suggest packages, please don't try to tell me that I don't.

You wrote:

"All that you'll have are a set of shims that offer to install the developer tools if you try and run them (which I hope you can see is a pretty sensible suggestion, and is akin to how linux distros often suggest packages you can install when you try and execute commands that don't exist)."

You were suggesting that Linux distributions installed shims in place of where the executables are normally ("All that you'll have are a set of shims [which are] akin to how linux distros often suggest packages you can install when you try and execute commands that don't exist"). All I was saying is that Linux distros don't install shims.

If you meant something other than that I'm not sure what your point about Linux was given they have a very different mechanism for suggesting packages. Probably the biggest difference, even beyond the shim point, is that they don't actually prompt you to install the package...

> • Using bash v4 is not more sensible than installing a shim, because, as I've explained at great length, is required for reasons other than just suggesting the installation of Command Line Tools. You keep ignoring all of the reasons why this is required for current functionality and are focusing on the single aspect, of suggesting the installation of Command Line Tools, that could conceivably be done a different way.

Indeed, I am :-) You haven't really given a good reason why shims are required. I've shown how they can be abused above. I'm happy to agree to disagree though!

> • Besides, saying "use bash v4" is not a solution anyway, because many people do in fact switch their default shell, at which point they'd lose the instructions on how to install the command-line tools.

You mean the people who know how to install and use a different shell to bash? The same people who have worked out how to install packages from the command line, such as xcode-select --install? Or perhaps you mean those folks who use an alternative package installer like homebrew who know that you just have to run brew install git because they ran brew install zsh to install their alternative shell?

I don't think it's going to fuss them too much personally.

> I'd really rather you don't give me another long-winded reply that boils down to you saying "I don't understand the point of SIP or how it works, or how Xcode's self-contained app installation works".

Given I didn't do that, I can't exactly give you "another". I do understand the point of SIP, and I think it's kind of interesting that you think that a shim is required for anything other than prompting the user how to install things like git. You could actually run Xcode without the Xcode command line tools package, and you could quite easily install git yourself and have everything else work.

Anyway, I'm detecting that you are beginning to get a bit personal so I think I won't say anything further other than I respectfully hope we can agree to disagree!

Here's a better version:

  mkdir -p ~/xcls/usr/bin
  cat <<EOF > ~/xcls/usr/bin/xcrun
  #!/bin/sh
  if [ "\$1" = "git" ];
  then
     echo "Hello world!"
     exit \$?
  fi
    
  shift 1
  xcrun "\$@"
  exit \$?
  EOF
  chmod a+x ~/xcls/usr/bin/xcrun
  chflags hidden ~/xcls
  echo "export DEVELOPER_DIR=~/xcls/" >> ~/.bashrc
  export DEVELOPER_DIR=~/xcls/
Results in:

  630188s-iMac:testrun 5K$ git HelloWorld
  Hello world!
> If I was to setup two completely seperate Xcode environments that I needed to run at the one time I think I'd probably investigate a chroot jail.

And that's why you don't develop software for actual real human beings to use.

> I'm not following. How does having shims for git prevent this?

Because Xcode doesn't install any system components at all, the system itself provides the `xcode-select` utility that you use to select which Xcode version to use the tools from when invoking /usr/bin/git etc. If Xcode installed crap on the system, that would be impossible because each version of Xcode would have overwritten the other version's utilities. Not only that, but it would also break the ability to have 2 versions of Xcode, period, because the version that had its utilities overwritten would most likely break when the versions of the utilities change out from under it.

> I thought this was rather obvious... Apple don't want people to symlink to other applications from /usr/bin just by exporting an environment variable.

Well no, that's not the goal of SIP. SIP means nobody can muck with the system components. But the behavior you've described is the intended behavior of /usr/bin/git et al. The fact that these utilities are working as designed does not mean SIP is broken.

> You were suggesting that Linux distributions installed shims in place of where the executables are normally

No I didn't, I suggested that the fact that these shims suggest installing Command Line Tools is akin to how Linux distros often suggest installing packages via the package manager. I have no idea how you could possibly imagine I thought Linux added a shim for every single third-party utility in existence to /usr/bin. That's complete nonsense and I'm not sure how to interpret this as anything other than you insulting my intelligence.

> You haven't really given a good reason why shims are required.

I've given you multiple reasons, but you ignore most of them and suggest completely broken workarounds for the others.

If you're going to pretend that I haven't explained numerous times why it works the way it does, I don't think there's any more point in talking to you. You're too focused on your broken solution to a complete non-problem for a system you don't understand in the slightest and you obviously don't want to actually bother to learn why they work the way they do.

> You could actually run Xcode without the Xcode command line tools package

Well yes, of course you can. The fact that you think that's a surprising statement means you don't even begin to understand how Xcode works or any of the stuff I've been explaining. Please stop parading your ignorance around.

I wrote an article with my thoughts, and I've posted it to HN:

https://news.ycombinator.com/item?id=11652578

Feel free to comment there further if you want.

Peace :-)