171–180 of 385 posts
Earlier quoted context omitted.
It's a bit too precarious to be an adequate solution, in my opinion. It depends on /usr/local/bin always being ahead of /usr/bin in $PATH, and on scripts never invoking the system git via its full path, and on Homebrew never accidentally uninstalling git due to a botched upgrade. Not to mention the fact that Homebrew itself uses the system git to install itself.
When would the order of $PATH vary?
Earlier quoted context omitted.
Yes we did, and the author appears to be posting with the primary intent of spreading anti-Apple sentiments. The opening paragraph begins by insulting startups for being full of Macs. The rest of the post is full of snide comments. They go off on a tangent about System Integrity Protection and the fact that OS X is not Linux ("Apple... keeps you from twiddling", "Well, sorry. You also can't chmod", "I'll just strace…
The opening paragraph reads: "Sometimes I think about all of those pictures which show a bunch of people in startups. They have their office space, which might be big, or it might be small, but they tend to have Macs. Lots of Macs. A lot of them also use git to do stuff, perhaps via GitHub, or via some other place entirely. There are lots of one-off repos all over the place." If you can see a cheap shot in that parag…
>> I know, I'll just strace it to see what it execs! Oh wait, this isn't Linux. Uh, I'll dtruss it to see what it execs!
Someone who is not in the process of bashing as much as possible would have simply said something like "I'll dtruss it (OS X's equivalent to Linux's strace) to see what it execs". All the exclamation marks and passive aggressive "Uh", "Oh wait", "Well, sorry" phrasing to drive home just how terribly awful the operating system is.
The closing section with the "If you rely on machines like this, I am truly sorry" sealed it. This clear dislike for the ecosystem adds - at least for me - new meaning to the opening paragraph. Typical startup bashing for "trying to be hip and trendy". It's hardware and an operating system. Everyone has a preference for the tools they use; there's no need for passive aggressive hostility.
Earlier quoted context omitted.
And at this point the first instruction for any OSX user who downloads and compiles anything is "Install Homebrew"
The Homebrew installation process uses the system git.
Earlier quoted context omitted.
It's times like this that prove I made the right choice sticking to Linux. There's nothing I hate more than the inability to fix things that are broken on my system or the fact that I would have to jump trough a lot of unnecessary hoops to do it. The few small advantages are just not worth it in the end for me.
There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…
> They are basically screwed until Apple deigns to > deliver a patched git unto them Actually, no. Don't use the tools that come pre-installed. All you have to do* is: brew install git *and make sure that brew installs are prioritised in your $PATH. Which you should do anyway.
Just installing git from Homebrew or MacPorts is not enough to be safe from this remote code execution.
Earlier quoted context omitted.
No, I'm just bored of faux-outrage and agenda pushing. If this is such a critical issue, then reboot your Mac and disable SIP. 5 minutes and done. In the time it's taken you to post all your comments here, you could have fixed it. [edited to add] It's not like SIP was a secret - it was one of the major features of El Capitan. Didn't you do any research before upgrading your mission critical server to El Capitan?
You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway. https://github.com/gdbinit/rootfool Incidentally, calm down a bit - you sound pretty outraged yourself! You m…
From their readme: "P.S.: 10.11.4 update removed csr_set_allow_all() function used to enable/disable SIP. It means this code does not work on El Capitan 10.11.4 or newer versions when released."
Also even when it did work it needed you to get a Kernel Extension signing certificate from Apple - which they could (probably) revoke pretty easily when they saw it being misused.
> They are basically screwed until Apple deigns to > deliver a patched git unto them Actually, no. Don't use the tools that come pre-installed. All you have to do* is: brew install git *and make sure that brew installs are prioritised in your $PATH. Which you should do anyway.
Then you will get caught by some GUI that uses /usr/bin/git. Be aware changes to PATH in your shell startup files do not affect graphical applications at all. Just installing git from Homebrew or MacPorts is not enough to be safe from this remote code execution.
Earlier quoted context omitted.
There's a security feature on El Capitan that essentially makes certain files and directories on your host system immutable. Presumably it's some set of filesystem flags, but not even root can change them. There's a magic nvram command you can use to disable the security feature (which if you're a developer you'll have to do eventually since you can't touch anything in /lib or /usr/bin or /bin). The command in questi…
> It will fail. So presumably SIP correctly propagates permissions to all dentries. I'm not sure what's happening then. /usr/bin/git is a small wrapper that invokes the actual git from either the command line developer tools or from xcode (whatever you have selected with `xcode-select`)
Earlier quoted context omitted.
The opening paragraph reads: "Sometimes I think about all of those pictures which show a bunch of people in startups. They have their office space, which might be big, or it might be small, but they tend to have Macs. Lots of Macs. A lot of them also use git to do stuff, perhaps via GitHub, or via some other place entirely. There are lots of one-off repos all over the place." If you can see a cheap shot in that parag…
I didn't get a negative vibe from the opening paragraph on its own. If you read the rest of the post, you find a lot of unnecessary negativity regarding the entire Apple ecosystem. >> I know, I'll just strace it to see what it execs! Oh wait, this isn't Linux. Uh, I'll dtruss it to see what it execs! Someone who is not in the process of bashing as much as possible would have simply said something like "I'll dtruss it…
As for the "If you rely on machines like this, I am truly sorry" - I don't really blame her. She says she's sorry because she was trying to administer a system that a. has vulnerable software she couldn't easily upgrade or even remove, and b. some of the common utilities that she uses to troubleshoot Unix systems just don't work and this makes a competent Unix admin's life harder than it needs to be.
And Rachel, by all accounts, is a very competent - no, scratch that - talented administrator. So she feels the pain of not being able to use commonly available tools and not being able to keep systems as secure as she would like.
If you feel offended by this, then it seems to me you are actively looking to be offended and you have your own agenda.
Earlier quoted context omitted.
You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway. https://github.com/gdbinit/rootfool Incidentally, calm down a bit - you sound pretty outraged yourself! You m…
Rootfool doesn't work any more. From their readme: "P.S.: 10.11.4 update removed csr_set_allow_all() function used to enable/disable SIP. It means this code does not work on El Capitan 10.11.4 or newer versions when released." Also even when it did work it needed you to get a Kernel Extension signing certificate from Apple - which they could (probably) revoke pretty easily when they saw it being misused.
Of course, there is a utility that sets the flag in recovery mode, unless there is a specially built kernel that only exists in that mode (I'm no OS X expert, there could be) then there must be some way of bypassing the protections. If you can still load a kernel extension then it occurs to me that you can still bypass it.