131–140 of 385 posts
Earlier quoted context omitted.
So you install development tools like XCode on a server?
Some folks install git on the server, sure. Do you know every single use case of every single server?
Why would you install Xcode on such a important box?
Earlier quoted context omitted.
Inability to manually update the copy of a tool located in /usr is par for the course with most Linux distributions - in that case the kernel won't stop you from replacing the files (unless your distro has the root FS mounted RO), but the package manager will typically replace them right back the next time there's a minor update (same for OS X updates pre-SIP), and it's easy to accidentally break things. Instead, the…
Right, if its so easy then why don't Apple update git more frequently then?
I'm confused about how 'Macs' and 'free software' go together?
Earlier quoted context omitted.
Some folks install git on the server, sure. Do you know every single use case of every single server?
I'm talking about how you got this version of git on this server. A server that's so mission critical that you're not allowed to reboot it. Why would you install Xcode on such a important box?
And if I want to troubleshoot something odd, it would be nice to be able to hook in dtrace - without rebooting the server, flipping a switch to disable the "feature", and then troubleshoot my server's issue.
Initially I was shocked that the vendor has files on the system that cannot be changed by the user.. but now I think there is more to it. The real thing that is bugging me, is finding out what /usr/bin/git really is.. which this article doesn't answer. Is it a standalone immutable executable that the file system is aware of, or something else? Right now, I wish I had a mac.
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…
/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.
I'm talking about how you got this version of git on this server. A server that's so mission critical that you're not allowed to reboot it. Why would you install Xcode on such a important box?
You are missing the wider point I fear. You seem to be so focused on git that you miss the point that there are other system utilities that are installed in /usr that you might need to patch. And if I want to troubleshoot something odd, it would be nice to be able to hook in dtrace - without rebooting the server, flipping a switch to disable the "feature", and then troubleshoot my server's issue.
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?
Earlier quoted context omitted.
Right, if its so easy then why don't Apple update git more frequently then?
Perhaps they should. But then again, a large percentage of Linux users use distros that lag even further behind (albeit arguably with a better security fix backporting process)... stability is valuable too.
Apple are known to be tardy in taking their time to release security fixes unfortunately. This whole point might be mitigated if they were more responsive, but they aren't terribly. Your average Linux distro is far faster at updates even on LTS releases than Apple...
Earlier quoted context omitted.
Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.
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.
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 point where you apparently have control of the system already.
In comparison with linux, this vulnerability pales in comparison to the-common-void-that-shall-not-be-talked-about, i. e. the around 400 gems, npms, brews, pips, go(es?), roles and ppas installed & running on a typical dev workstation, no matter if it's Linux or Mac. It's just a matter of time until someone gets his version of leftpad installed on >100,000 workstations & servers before he flips the switch to turn them into cryptolocked hostages.
Also: I'd hate if I had to fiddle around with kernel parameters to get printing, sleeping, networking, waking, font-displaying, account-switching, video-playing, time-knowing or up-backing to work every time canonical decides it's time for a new subsystem. I love linux on the server, but maintaining a function desktop system is simply a waste of time. A somewhat evil waste of productivity, actually, because it feels like work and at the same time provides those frequent little victories that can turn it into an obsession.