Rogue Source Code Repos Can Compromise Mac Security Due To Old Git Version (softpedia.com)

An anonymous reader writes: Recent Mac versions come bundled with a very old version of Git (2.6.4) that is vulnerable to two security flaws that allow attackers to execute code on the device when the user forks a Git repo holding "malicious" code. The problem is that users can't upgrade this Git repo, they can't change its runtime permissions, nor can they remove it because Apple blocks even root users from twiddling with some system-level programs. "If you rely on machines like this, I am truly sorry. I feel for you," the researcher wrote on her blog. "I wrote this post in an attempt to goad them [Apple] into action because this is affecting lots of people who are important to me. They are basically screwed until Apple deigns to deliver a patched git unto them."

Comments

Compile and path

[Moblaster]

Well why can't you just compile a new git and stick it in your path?

Re:Compile and path

[Anonymous Coward]

Because OS X resets PATH to the system defaults stored in /etc (which you can't edit for the same reason you can't update git) on anything launched by launchctl, which is basically anything you don't launch directly via the shell.

Re:Compile and path

[Anonymous Coward]

You also certainly can edit things stored in /etc.

And have you ever heard of ~/.profile to set your PATH?

Furthermore, /usr/bin/git isn't even git. It's just a wrapper around xcselect to *FIND* git within Xcode.

Re:Compile and path

[fnj]

OS X resets PATH to the system defaults stored in /etc (which you can't edit for the same reason you can't update git) on anything launched by launchctl

This illustrates why horse-shit abortions tacked onto unixoids (launchd, systemd, SELinux, AppArmor, NetworkManager, PulseAudio, etc) get in the way and impede what people who know what they are doing (or TRYING to do) at least as much as they may satisfy some developers' wet dreams.

Re:Compile and path

[Anonymous Coward]

~/.profile won't work, because launchctl ignores it.

In OS X, programs that are launched from the GUI have never touched an actual shell. Their parent process is "launchd" and "launchd" is init. As I understand it, as of OS X 10.9, launchd simply hardcodes the PATH and entirely ignores the contents of /etc. Prior to that it would use /etc/environment or something like that (but not /etc/profile).

When you launch something from the Dock or double-clicking on it, it's launched via launchctl and that ultimately execs it off launchd. It never sees a shell and never sees ~/.profile.

So you can replace git and use a different git in shells you start, but if you want to prevent, say, an IDE from using the system git it finds via the PATH - you can't. There's no way to adjust the PATH that the majority of applications use.

Re:Compile and path

[Anonymous Coward]

You can also update the system path with the following and reboot.

sudo launchctl config system path 'xxx'

Re:Compile and path

[Darinbob]

You can fix this stuff. True, the latest El Capitan crap tries to prevent root from doing some things but you can override it with the secret mantra easily found in web searches. Anyone using "git" on OSX is probably already using Mac Ports or something similar. The default tools that come with OSX or Xcode really only exist as an iOS development support system and can be ignored.

Re:Compile and path

[cbhacking]

In what way are AppArmor or SELinux in any way like launchd or systemd? Also, while you may be super 1337 and sandbox all your applications using chroot jails and who-knows-what-else, AA and SEL provide a hell of a lot more security than what people normally do, which is just run programs as whatever user you happen to be logged in as.

Re:Compile and path

[lucm]

You are technically correct but SElinux is a real pain in the ass.

This reminds me of the hilarious definition of Level 2 in the CIS benchmark for RHEL:

Level 2: may negatively inhibit the utility or performance of the technology

https://benchmarks.cisecurity....

There comes a point where hackers cause less damage than this kind of "security".

Re: Compile and path

[Anonymous Coward]

It says that you are prevented from doing certain things as root because of the changes that were done... right in the summary

Re: Compile and path

[jeremyp]

Changing the path with launchctl is not one of them.

Re:Compile and path

[jeremyp]

The default tools that come with OSX or Xcode really only exist as an iOS development support system and can be ignored.

Yes, and I do. However, if you use the git integration of Xcode itself, it is hard coded to use the built in to Xcode version of git i.e. the vulnerable one.

Of course, nobody in their right mind uses the Xcode source control because it is rubbish.

Re:Compile and path

[Anonymous Coward]

You absolutely can. I'm using git 2.8.0 on El Capitan installed via homebrew. The included version is 2.6.4. You need to tweak your /etc/paths and/or /etc/paths.d settings, install homebrew, then do 'brew install git'.

Re:Compile and path

[Anonymous Coward]

CyberArk. . . .

(Posting AC because complaining about this product could have direct consequences for me.)

Re:Compile and path

[Anonymous Coward]

It would figure that looking up how to do that via a Stack Overflow question got the answer "it can't be done" but saying "it can't be done" on Slashdot got me the right answer.

Re:Compile and path

[Anonymous Coward]

Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?

Re:Compile and path

[Anonymous Coward]

And why would that be a problem? Git is a command line binary, and hence that's where you launch it from. If some GUI is calling it with a shell environment, well, sucks for them and they are going to have many more problems.

Instead of using the environment they can detect the path to the git binary and let the user change it. I've seen apps do that, letting you specify a different git, especially useful if for some reason you don't have admin rights and installed it from source in your $HOME or simply don't want to mess with the OS (I'm looking at you, disgusting homebrew).

Re:Compile and path

[Anonymous Coward]

~/.profile won't work, because launchctl ignores it.

In OS X, programs that are launched from the GUI have never touched an actual shell. Their parent process is "launchd" and "launchd" is init. As I understand it, as of OS X 10.9, launchd simply hardcodes the PATH and entirely ignores the contents of /etc. Prior to that it would use /etc/environment or something like that (but not /etc/profile).

When you launch something from the Dock or double-clicking on it, it's launched via launchctl and that ultimately execs it off launchd. It never sees a shell and never sees ~/.profile.

So you can replace git and use a different git in shells you start, but if you want to prevent, say, an IDE from using the system git it finds via the PATH - you can't. There's no way to adjust the PATH that the majority of applications use.

Is there an IDE that exists today that does not let you tell it the exact path to your version control binaries?

Re:Compile and path

[Anonymous Coward]

Or even better tweak your /etc/paths.d/ (required for homebrew, which incidentally includes a much newer git). That way you have the best of both worlds - your system binaries are protected from being replaced by rootkits but you can still install custom versions of software if needed.

Re:Compile and path

[Anonymous Coward]

Sure but the thing was how do you make Xcode and all other things that use Git use your updated Git instead of the broken one Apple provided?

Re:Compile and path

[Guy Harris]

Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?

Well, you definitely should not be surprised.

(I.e., Lennart likes the idea of launchd.)

Re: Compile and path

[Anonymous Coward]

Root is root.

If I have root privileges, I don't expect the system to prevent me from doing *anything* I feel like doing.

Call this fake-root or pseudoroot, whatever it is, I'm not interested. I won't be satisfied if I don't have 100% control over the OS on hardware I own.

Re:Compile and path

[Anonymous Coward]

Uh, yeah, like every other daemon whose executable ends in 'd'?

inetd
ftpd
crond
fingerd
syslogd
ntpd
etc.

Re:Compile and path

[Anonymous Coward]

Yep! Fuck you, Eclipse!

Although it wasn't for git because as I recall Eclipse's built-in git support uses some horrible Java port of git, it was (ironically enough) because it was impossible to point it to locally installed versions of Java-based tools without modifying the PATH directly.

Re: Compile and path

[Keybounce]

As part of anti-malware prevention, Mac OS X protects a number of critical files from being modified, even by root.

There are two work-arounds:

1. Install a second copy of the OS (repartition the drive to include a second partition).
2. Use the recovery boot

In both of these cases, the system files relative to "/" are still protected, but the files in /Volumes/RealRoot/usr/bin/whatever are now not protected.

** NB: The list of protected files is itself contained in a file! **

Said file is protected, but you *can* boot in the recovery boot, empty that file (or other specify that the entire disk is not protected), and then you have full control (And exposed risk) as root.

So you can disable or work-around this feature.

Re:Compile and path

[Plumpaquatsch]

Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?

Depends on what you want to achieve. If it helps your decision, launchd is 10 years old, systemd only 5.

macports

[feranick]

sudo port install git
Not that complicated.

What's the impact on Rust?

[Anonymous Coward]

While I'm sure I could correct this as you describe, what I'm worried about is what impact this might have had on my checkout of the Rust programming language implementation's source code. As we all know, Rust's code is hosted on GitHub and its development is done there. If I checked out Rust on a Mac using the native git client does it mean that something could have happened with the Rust source code I checked out? Is there any way that I can verify that the Rust implementation code I have checked out is the correct code?

Re:What's the impact on Rust?

[Anonymous Coward]

According to a hackernews article on the exploit, GitHub verifies all repositories that they host, so if you clone from GitHub you shouldn't need to worry about this exploit.

Re:What's the impact on Rust?

[Anonymous Coward]

Also explained on the GitHub blog:
https://github.com/blog/1938-vulnerability-announced-update-your-git-clients

Re:What's the impact on Rust?

[Anonymous Coward]

Hipster Alert! Hipster keywords detected: Mac, Rust, Git, GitHub.
This post is probably by a hipster or a hipster-troll, dont read into it.

It's Impossible!!!

[konohitowa]

sudo port install git
echo "export PATH=/opt/local/bin:\$PATH" >> ~/.bashrc

Oh! The humanity!

(Requires https://www.macports.org/insta...)

As an aside, it's possible to override SIP, but it's a bit of a PITA.

Re:It's Impossible!!!

[Anonymous Coward]

whoa whoa whoa... you must be using your keyboard wrongly....

Re:It's Impossible!!!

[93 Escort Wagon]

Yup, boy howdy that was hard.

$ git --version
git version 2.6.4 (Apple Git-63)
$ fink install git
... chatty installation text ...
$ hash -r
$ which git
/sw/bin/git
$ git --version
git version 2.8.0
$

  But, still, it is annoying that a lot of the various standard developer tools provided by Apple are significantly older than their current counterparts on most other Unix systems.

Re:It's Impossible!!!

[Anonymous Coward]

or

brew install git

(uses homebrew: http://brew.sh/)

Re:It's Impossible!!!

[Anonymous Coward]

The version included in Xcode 7.3 was released by upstream git maintainers just a couple months before Xcode 7.3 GM'd. That's pretty damn recent, and given that Xcode 7.3 is a dot release, I'd expect them to not consider jumping to a new major version of git once they start seeding to developers unless there's something very important in that new major version of git.

What changes between 2.6.4 and 2.7.2 do you think are so important that they warrant the risk of potentially breaking Xcode's SCM system that sits above it?

Re:It's Impossible!!!

[fnj]

sudo port install git
echo "export PATH=/opt/local/bin:\$PATH" >> ~/.bashrc

Oh, how clever. You've built in a dependency on the shell being bash and no other. Also, that won't affect the PATH seen by cron jobs.

Re:It's Impossible!!!

[Anonymous Coward]

Ah here is a neat library for a program I am writing. I'll clone it using the interface on my IDE. Wait, what is it doing? dfsjij)S(*)*# NO CARRIER

Re:It's Impossible!!!

[konohitowa]

Oh, how droll. You assume /.-ers are imbeciles incapable of handling the command line.

Re:It's Impossible!!!

[Anonymous Coward]

You must be new to UNIX, BSD and stuff. .bashrc is only sourced when you start bash.

Most of the time, bash is not even run.

Please tell your security manager to keep an eye on you. CLI tools are not restricted to bash.

Re:It's Impossible!!!

[konohitowa]

As I expected, spending 5 minutes typing a simple example to make a point brought the insecure people out of the woodwork.

Re:It's Impossible!!!

[mwvdlee]

What changes between 2.6.4 and 2.7.2 do you think are so important that they warrant the risk of potentially breaking Xcode's SCM system that sits above it?

Apparently not security fixes; those aren't important enough for Apple.

Re:It's Impossible!!!

[jeremyp]

You don't need the second line. MacPorts automatically adds the correct path to your profile to make it override the built in tools.

Re:It's Impossible!!!

[Khyber]

Most current /.ers certainly can't handle the command line. They were born in the age of the GUI.

How thoughtless of you.

Re:It's Impossible!!!

[jeremyhu]

There were no security issues addressed between 2.6.4 and 2.7.2. The vulnerability was fixed in 2.7.4, but I understand your confusion because upstream incorrectly advertised the issue as fixed in 2.7.1 on March 15 before actually fixing it in 2.7.4 on March 17.

Yes, you *can* replace /usr/bin/git

[Guy Harris]

First, you turn off System Integrity Protection by following the directions on Apple's Configuring System Integrity Protection page.

Then, you replace it (or any other program you want, including /System/Library/Kernels/kernel).

Then, if you want, you turn System Integrity Protection back on.

Re:Yes, you *can* replace /usr/bin/git

[Rockoon]

I'll get my grandmother on that.

Re:Yes, you *can* replace /usr/bin/git

[Guy Harris]

I'll get my grandmother on that.

If your grandmother uses Git from the command line on her Mac, and would otherwise be capable of replacing /usr/bin/git, she might not find the extra steps described in Apple's document too problematic.

Re:Yes, you *can* replace /usr/bin/git

[Space cowboy]

If your grandmother is checking out code from a git repository (and much kudos to her if so) then she won't have a problem disabling SIP...

Re:Yes, you *can* replace /usr/bin/git

[timritzer]

Lol, your grandmother is regularly forking unknown source repos? Because if so, she can handle fixing it....

Re:Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

You should. She apparently already installed Xcode and is forking various git repos.

Re: Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

Don't worry, it's most assuredly coming. When they move to ARM-based Macs, they'll ensure that the kernel is signed by Apple, and then the hilarious idea that Apple hardware is something you "own" and not something you pay Apple to use will finally be put to bed.

Re:Yes, you *can* replace /usr/bin/git

[kuzb]

...just as soon as you finish training her to use version control.

Re: Yes, you *can* replace /usr/bin/git

[Guy Harris]

Apple thinks the users of their products are too stupid to handle root account.

If you mean "Apple makes it hard to log in as root", true, but so what? About the only OS into which I log in as root these days is Solaris 10, and that's because they don't let you do a clean shutdown of the system as an ordinary user (unless I've missed something) - I use sudo or su in those cases where I need to do stuff as root.

What makes Apple think their users understand SIP?

Most of their users neither understand it nor need to understand it.

Some of their users do need to understand it, and can understand it; that article is published for them.

Re:Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

The exploit is about a GUI program that invokes git, not using git from the command line. It is just an example of the many outdated tools Apple refuses to update in a timely manner. Instead, the company routinely waits for the yearly releases.

Re:Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

How dare you fight against Apple's supreme power and use your machine to do that? You only get a opportunity to rent the device for three years, you don't own it.

Re: Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

The problem is that the first account a user sets up when they buy a Mac is an administrator account. Regardless of what they told users, most would just set up that account and use it all the time. So when some installer launched and said it needed your password to complete installation people would blindly enter their admin password and the program (potentially malicious) would have root access and could modify the system. If you really consider yourself a pro you can go through the SIP disabling procedure, but creating a password with root privileges is no longer part of the standard guided setup procedure. It's a perfectly fine balance between security for the average user and customizability.

Re:Yes, you *can* replace /usr/bin/git

[lucm]

Two points.

1) forking github repos has long stopped being something that requires deep technical skills, it's basically the modern Download.com

2) Apple products are supposed to be designed for regular people and Apple ecosystem is supposed to be closed so they can control quality. Fail and fail.

Re:Yes, you *can* replace /usr/bin/git

[Guy Harris]

The exploit is about a GUI program that invokes git, not using git from the command line.

The exploit is about the git program. The only difference between the GUI program running it and running it directly from the command line is that you can set $PATH so that the command git would run a newer version from /usr/local/bin or ~/bin or wherever, whereas that's more difficult or even impossible to do so from, for example, Xcode.

And, in any case, if your grandmother uses Git from Xcode, and would otherwise be capable of replacing /usr/bin/git, she might not find the extra steps described in Apple's document too problematic, so the "I'll get my grandmother on that." comment was extremely idiotic.

Re:Yes, you *can* replace /usr/bin/git

[Guy Harris]

How dare you fight against Apple's supreme power and use your machine to do that?

Because Apple helpfully told me how to do it.

Re: Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

What a shitty SIP.

Microsoft Windows has this. If you turn it off, modify files that are not signed properly, then turn it back on... it complains system files have changed.

You have to specifically make an exclusion or use only properly signed files.

Re: Yes, you *can* replace /usr/bin/git

[Guy Harris]

What a shitty SIP.

Microsoft Windows has this. If you turn it off, modify files that are not signed properly, then turn it back on... it complains system files have changed.

You have to specifically make an exclusion or use only properly signed files.

Are you referring to Windows File Protection, Windows Resource Protection (which apparently replaces Windows File Protection in Vista and later), or some other mechanism?

So presumably there's some way to turn off protection of a particular file without turning the protection off entirely; otherwise, this is just like System Integrity Protection, with "turn off protection of a particular file" being done by turning its "restricted" flag:

$ ls -lO /bin/cat
-rwxr-xr-x 1 root wheel restricted,compressed 23520 Jan 13 18:13 /bin/cat

with

sudo chflags norestricted

on the file, which you could do on OS X only when System Integrity Protection turned off.

Re:Yes, you *can* replace /usr/bin/git

[Anonymous Coward]

Uh, with GUI tools quite a few really ordinary users are using some kind of version control, it isn't any harder to learn than an email client really.
No, they won't ever work on a shared repository, do merges or other complicated stuff.

Re:Yes, you *can* replace /usr/bin/git

[Aaden42]

1) forking github repos has long stopped being something that requires deep technical skills, it’s basically the modern Download.com

What universe are you living in? I’m pretty confident saying that zero of the humans I know who don’t work directly in programming-related IT fields don’t even know what ‘git’ is. The British non-coder folks I know might think I’ve just insulted them, but other than that, blank faces all around.

That kind of thinking from a rarified environment is why simple things that “we all know” we shouldn’t do turn into huge security issues. We all know, but they don’t. They outnumber we by a huge margin. And FSM willing, they always will. That’s called “job security.” You can’t create interfaces built on the assumption that users have the same background knowledge that we’ve acquired through years or decades of daily immersion. When security fails in those situations, it’s the programmer, not the user who did something stupid.

Re: Yes, you *can* replace /usr/bin/git

[Aaden42]

If you *modify* a signed file, thus invalidating the signature, neither Windows nor OS X will run it, SIP or not. When you turn off SIP, replace a signed file with an unsigned one OR a file validly signed with another key, then you can turn SIP back on, and the file you modified stays as you left it.

To my knowledge, there is no way to get OS X to run an invalid signed file (IE signed, but modified since it was signed). There’s not even an override for that (nor should there be, IMHO). OS X tells you the file is damaged and moves it to the trash. You could strip the signature and run it that way if you wanted, but as long as there’s an invalid signature attached, it won’t execute, regardless of SIP settings.

Re: Yes, you *can* replace /usr/bin/git

[Space cowboy]

Away bollocks. You're just trying to score cheap points.

There is no way my mother (not speaking for OP's grandmother here) will ever open Terminal.app, let alone type in 'git clone xxxxx'. She doesn't know what 'download.com' *is*. For people like my mother, Apple computers are indeed better.

For tech-savvy developers (i.e. People who know what './configure' is, or 'make', following the step-by-step instructions for disabling SIP is trivial. Or, you know, they can just install macports (standard install package from a dmg), change their path to put /opt/local/bin first and then type 'sudo port install git'. Problem solved.or they can use fink, or they can use brew, or, since they're so up on git and they could just clone the git repository, build and install it themselves.

SIP is a good thing, even though it's a pain in my arse as a kernel extension developer. Sure, if a vulnerability shows up, there are more steps to fix it, but it will almost certainly be fixed in the next s/w update now, there are ways around the problem, and in general SIP stops malicious apps from replacing system binaries even when they have compromised the root account.

But hey, let's bash Apple huh ? Having actually read the post on the authors site, it reads like a six-year-old wrote it. It's full of biased opinion and even starts off with a chicken-little "oh the world is ending" allegory about those poor innocent small-business developers.

I wonder if the author went the responsible route of filing a radar with Apple and seeing what they'd do about it before announcing that the end of the world is nigh, or whether she just tried to score cheap internet points to bolster her own biased viewpoint about Apple products in general. Really, I wonder /s

Re: Yes, you *can* replace /usr/bin/git

[MrKrillls]

"For people like my mother, Apple computers are indeed better."

Maybe. Maybe not.

Someone is going to have to support Mom's computer. If it's a Mac, that person will have to be one level more savvy to get around Apple's user protective stuff. i.e. I won't be able to keep Mom's machine working because all the extra junk is one step beyond my knowledge. I'm not a developer - just a user who has figured out that the non-proprietary OSs are the sweet spot for user maintenance. Add proprietary and easy maintenance goes south.

Re: Yes, you *can* replace /usr/bin/git

[Space cowboy]

My mother has a Mac. She's 6000 miles away. Number of support calls needed over the past several years ? 0.

I installed it at Xmas one year when I was over there, and since then have had zero trouble with it. Now my brother has to maintain my father's PC now and then (example: he clicked the UPS email when UPS were indeed delivering that day), but *fortunately* he's only a couple of hundred miles away /s

I stand by the statement. For people like my mother, Apple computers are indeed better.

Re:Yes, you *can* replace /usr/bin/git

[Guy Harris]

There are programs other than XCode that might use git as well.

Yes, but that's irrelevant to the point, which is the the original crack about the grandmother demonstrates nothing other than that Rockoon hadn't bothered to engage their neocortex when making the crack - yes, there are other GUI programs that might use Git, but if your grandmother is using one of them, and is capable of replacing /usr/bin/git, it's very likely that your grandmother has enough technical chops to turn off System Integrity Protection.

You're a cheerleader,

No, I'm somebody who doesn't like bogosity (such as "Apple completely prevents you from replacing /usr/bin/git") being propagated.

so I understand your intense need to defend Apple,

I'll defend anything, from anybody, from what I think to be technically incorrect and false criticism. Perhaps the problem is that the current favorite target of ill-informed foeboys happens to be Apple, so there's currently more ill-informed criticism of Apple than of, say, Microsoft or the Linux community, but I've blasted ill-informed criticism of Windows and Linux in the past as well.

And I'm perfectly willing, for example, to rip Apple's protection of programs in /usr/bin that merely run other unprotected programs in /Applications/Xcode.app/Contents/Developer/usr/bin or elsewhere for being a royal pain, breaking, for example, attempts to run /usr/bin/lldb from libtool to debug a built-with-libtool binary in its build directory. (Yes, I filed a Radar. Yes, they blew it off.)

but try to think a little every once in a while.

I do so all the time. You might want to try it yourself, for a change.

Re: Yes, you *can* replace /usr/bin/git

[lucm]

But hey, let's bash Apple huh ?

There has been no Apple bashing in this thread. Not getting on one's knees to worship Apple is not the same as bashing Apple.

You remind me of those people who say they've been cyber-bullied because nobody "Liked" a comment they posted.

Re: Yes, you *can* replace /usr/bin/git

[Space cowboy]

From the post above mine, which I was replying to:

"Apple products are supposed to be designed for regular people and Apple ecosystem is supposed to be closed so they can control quality. Fail and fail."

"Fail and fail" is generally considered to be uncomplimentary. Just FYI.

Re: Yes, you *can* replace /usr/bin/git

[lucm]

"Fail and fail" is generally considered to be uncomplimentary. Just FYI.

And you consider that bashing? Have you been raised by hippies?

Re: Yes, you *can* replace /usr/bin/git

[Space cowboy]

I'm not sure what hippies are, so I doubt it, but I do understand what politeness and manners (and their opposites) are.

Forking is for GitHub

[Anonymous Coward]

When you make a copy of a git repository on your machine, it's called "cloning" the repo. "Fork" is a GitHub buzzword.

Re:Forking is for GitHub

[Anonymous Coward]

In a distributed VCS like git, there isn't really a distinction between clone and fork.

Re:Forking is for GitHub

[bondsbw]

In a distributed VCS like git, there isn't really a distinction between clone and fork.

The operation is the same but the purpose is different... a fork provides the ability to push changes to the hosting service when you don't have write access to the original repository. A local clone is usually distinguished from a fork in this way.

Re: Forking is for GitHub

[Anonymous Coward]

Ur face is a buzzword.

Very old?

[Anonymous Coward]

I'm annoyed this is a problem and would like Apple to fix it, but using bullshit to spread a story is a bit counter-productive.

It's not old (about 4 months since release, mid-Dec 2015) and unless you're using integrated git in Xcode, very easy to upgrade via brew or macports.

Re:Very old?

[Anonymous Coward]

There have been two 10.11 updates since mid-Dec. This should be considered critical since it is easy to invoke and no way to set a user path for programs executed from the GUI. Apple's record on security updates is pathetic and their lack of communication doesn't help matters. Unless they are prodded by the press, their standard position is to remain silent.

Re:Very old?

[jeremyhu]

Yes, there have been updates to OS X since December, but that's not at all relevant here for two reasons:
    1) OS X does not ship git
    2) The vulnerability wasn't fixed until late March (just a few weeks ago)

git 2.6.4 was shipped mid December, and Xcode 7.3 went to beta in early January (shortly after git 2.7.0 was released). Given that there were no security fixes in 2.7.0, 2.7.1, 2.7.2, and 2.7.3 and taking a newer version of git increases risk to Xcode due to changes in git, it's logical to expect that the version would not be updated to any of those versions after entering beta.

The git vulnerability was announced on March 15.
A fix was made available in git 2.7.4 on March 17.
Xcode 7.3 was released two business days later.

Obviously two days is not enough time for Apple to update Xcode's git to a new major version, thoroughly test it, ingest it into the Mac App Store, etc.

Re:Very old?

[jeremyhu]

Apple's record on security updates is pathetic and their lack of communication doesn't help matters. Unless they are prodded by the press, their standard position is to remain silent.

What makes you say that? Vulnerabilities fixed in Apple updates are well documented:

https://support.apple.com/en-us/HT201222

Re:Very old?

[Anonymous Coward]

> update Xcode's git to a new major version

Where does that nonsense come from?!? There's a git 2.6.6, are you claiming it doesn't contain the security fix?
If not, that is a major f-up by the git developers.
If it does (which I am fairly sure about since it was released on March 17th, too), Apple really hasn't the slightest excuse to not have shipped a patch within days. Even (ok, nowadays that probably is a bit unfair) Microsoft manages to do security updates in less than a month if it's a published issue.

Re:Very Old?

[Anonymous Coward]

You either trust upstream to maintain a stable branch and release 2.6.6 with limited testing (as it should contain no risky changes) or if you don't trust them you backport security fixes yourself.
In no way is "stick with your old version with security holes for months" a reasonable solution.

Re:Very Old?

[Lumpy]

It's an apple hate story that actually is devoid of anything useful.

Re:Very old?

[dgatwood]

You're assuming that the version Apple shipped is vulnerable to that CVE. Has anybody actually verified this? Apple has a habit of silently applying security fixes without pulling in a whole new version, to minimize the risk of inadvertently bringing in changes that break things.

Re:Very old?

[jeremyhu]

> update Xcode's git to a new major version

Where does that nonsense come from?!? There's a git 2.6.6, are you claiming it doesn't contain the security fix?

2.6.6 was released at the same time as 2.7.4. At the time that this vulnerability was announced (March 15), there was no 2.6.6. 2.6.6 was released two days after the announcement of the vulnerability leaving just two days before Xcode 7.3 release (which obviously isn't enough time to build, package, test, ingest, and ship)

If not, that is a major f-up by the git developers.
If it does (which I am fairly sure about since it was released on March 17th, too), Apple really hasn't the slightest excuse to not have shipped a patch within days.

Testing? Qualification? I personally don't want Apple to release software without actually testing it first.

This issue was disclosed at literally the worst possible time for inclusion in Xcode 7.3. Had it been disclosed earlier, it's likely that it could have been fixed in Xcode 7.3.

Re:Very Old?

[Anonymous Coward]

The bug in question was announced 2 *days* prior to the latest XCode release, and *also* prior to the announcement of the fix in git. (The fix, which, by the way, was *not* included in the version initially announced as including it.)

No version of the timeline includes sticking with known "security holes for months".

Re:Very old?

[Anonymous Coward]

> This issue was disclosed at literally the worst possible time for inclusion in Xcode 7.3. Had it been disclosed earlier, it's likely that it could have been fixed in Xcode 7.3.

You mean Apples has no process at all to provide security updates to Xcode so everyone has to wait for the next full update to fix it? That's just pathetic.
Because if they had such a process it wouldn't matter if it was in time for inclusion in a regular update or not.

Re:Very Old?

[Anonymous Coward]

The fix is available since one month and no update is in sight. That is very much sticking with a know security hole for months.
When 7.3 was released is COMPLETELY IRRELEVANT, I don't know why people keep bringing up that red herring.
If you can't fix a security issue in your software within a month after a patch is available you FUCKED UP as a developer. There is no other way to put this.

Read the headline..

[Anonymous Coward]

.. and immediately thought it referred to: rogue(6) - exploring The Dungeons of Doom

What's next? wumpus implicated in a devastating yet thoroughly boring and tedious phishing attack?

Re:Sunds pretty fishy

[Anonymous Coward]

It's called System Integrity Protection - intended to prevent the modification of system files that even root normally has no reason to touch. You can disable it, but honestly, you don't really need to.

She's Assuming Naive Devs, Then

[cmholm]

Granted, it's a bummer that Apple hasn't tended to the Git client shipped with Xcode.

That said, I'd argue just about anyone who takes the trouble to install and use Xcode and the associated command line stuff that comes with it is going to know how to steer ($PATH) around (fink, macports) a problematic tool once informed about it.

She got this onto Slashdot, so the hard part is on its way to being handled: getting the word out.

Re:She's Assuming Naive Devs, Then

[Anonymous Coward]

Exactly what release do you think that Apple *could* have tended to the Git client shipped with Xcode? Xcode 7.3 was released just days after the vulnerability, which means there was no time to include the fix at that point. Furthermore, the way in which the vulnerability was disclosed (prematurely, with incorrect details regarding fixed versions, etc) surely would not instill confidence in anyone shipping git to customers. I don't blame them for not delaying the shipment of Xcode 7.3 for this. Go wait for 7.3.1.

Re:She's Assuming Naive Devs, Then

[fnj]

Granted, it's a bummer that Apple hasn't tended to the Git client shipped with Xcode.

Also, just as one more example, even as of OSX 10.10 Yosemite, the shipped version of bash is prehistoric.

Re:She's Assuming Naive Devs, Then

[TheRaven64]

The version of bash shipped is the last GPLv2 version (plus patches). Apple doesn't ship any GPLv3 code.

Re:She's Assuming Naive Devs, Then

[Etcetera]

Are there any other kind?

*rimshot*

There are only three types of people I know who locally develop on Macs:
1) Devs developing a native Mac or iOS application
2) Devs who need to make substantive code changes (or test cycles) when they're off line
3) Devs who don't know how to log in to a remote server to do their development

For #1, you have my sympathies. #2 should go head to a bar, or spend time with the family instead of working after hours. #3 probably need to be hit with a clue-bat, which will hopefully dislodge that "devops" post-it note they've got attached to all their business cards.

Re:Ahahahahaha

[Anonymous Coward]

Just because you're too stupid to install a package and modify a path doesn't mean everyone else is too. Your comment just showcases how much you don't know.

Let me get this straight...

[the_other_one]

Does this mean that if your hardware vendor has a deity level above root then that is a bad thing?

Re:Ahahahahaha

[Anonymous Coward]

Because:

  - Windows / Linux don't have security issues, and never have
  - forking git repos containing malicious code is a real threat for the overwhelming majority of everyday Mac users

Simple fix to old rogue source code issue

[helixcode123]

sudo port install nethack

Re:Simple fix to old rogue source code issue

[Anonymous Coward]

You made my day. Here, have a dog.

d

Re: Sunds pretty fishy

[Anonymous Coward]

It's the punk "feature" that breaks mouse drivers on macs. Button 4 and button 5 for back and forward? No, no, use the $75 magic mouse (or whatever it costs) instead.

Re:Ahahahahaha

[NicknameUnavailable]

A flaw is a flaw and a shitty solution to have to implement is a shitty solution to have to implement. Get off Steve Jobs' necrotic dick.

brew install git

[Anonymous Coward]

brew install git

Re:brew install git

[softnewsit]

this is why it won't work https://www.reddit.com/r/netse...

Can't upgrade the repo?

[Anonymous Coward]

The problem is that users can't upgrade this Git repo, they can't change its runtime permissions, nor can they remove it because Apple blocks even root users from twiddling with some system-level programs.

Uh, it's not the repo that's under Apples control, it's the git application.

Re: Sunds pretty fishy

[Anonymous Coward]

lol wat r u on about

Not Apple's Fault

[Anonymous Coward]

It's not Apple's fault here. The git community developers completely and utterly botched this vulnerability. They announced it to the world, claiming it was fixed in 2.7.1 only to retract that a few days later after releasing 2.7.3 and then finally fixing it in 2.7.4. Apple released Xcode 7.3 just a couple days after git-2.7.4 was released, so it's no surprise that it doesn't contain the fix.

Had the git community actually disclosed companies ahead of the announcement (and better yet, had released a fix before the announcement, or even have been *accurate* in the announcent), the vulnerability likely would have been fixed in Xcode 7.3. As it is, developers need to wait for Apple to spin an updated version of Xcode for this fix.

The blame lies 100% on the git community for this debacle.

See https://marc.ttias.be/oss-security/2016-03/msg00195.php for more details about how they completely failed here.

Re:Not Apple's Fault

[Anonymous Coward]

Soooo a month later Apple still are unpatched. Sure the git community utterly fucking failed. but SO DID APPLE AND THEY STILL ARE FAILING. every piece of software will eventually have vulnerabilities and anyone publishing or including code needs to be able to update and maintain that code.

Re:Not Apple's Fault

[shawn2772]

The blame lies 100% on the git community for this debacle.

That was true for a few days after the release of 2.7.4, maybe even a few weeks, if we're generous. But the blame gradually shifts to Apple as time goes on and they leave the vulnerability unpatched. By now, it's 100% on Apple. It's not as though Apple doesn't have a mechanism for delivering patches, either.

Re:Not Apple's Fault

[Anonymous Coward]

Apple could have delayed their release instead of shipping known vulnerable code.

Re:Not Apple's Fault

[Trailer Trash]

The blame lies 100% on the git community for this debacle.

That was true for a few days after the release of 2.7.4, maybe even a few weeks, if we're generous. But the blame gradually shifts to Apple as time goes on and they leave the vulnerability unpatched. By now, it's 100% on Apple. It's not as though Apple doesn't have a mechanism for delivering patches, either.

To be fair to Apple, I typically download the X-Code updates on four or five different Macs here, about 1GB for each one. Multiply that out to all the Macs that are going to download X-Code. It's difficult to imagine the amount of bandwidth that they're burning with each update, it would suck to have to immediately do the same thing again.

Re:Not Apple's Fault

[Anonymous Coward]

To be fair to Apple, I typically download the X-Code updates on four or five different Macs here, about 1GB for each one

Presumably appstore updates support binary diffs since long ago. I can't believe updating git would generate a 1GB diff unless they are doing something really really odd.

Re:Not Apple's Fault

[shawn2772]

Why in the world would they download a complete X-Code replacement to change one small binary?

Re:Not Apple's Fault

[Anonymous Coward]

Because it's Apple. It's distributed within the XCode 'App' rather than as a separate package, so you have to update the entire App. Delta updates if you're lucky, but I don't think OSX uses that.

Re:Not Apple's Fault

[null etc.]

That's how Apple do.

Re:Not Apple's Fault

[shawn2772]

Not true. Many updates are much smaller than the whole package.

Re:Not Apple's Fault

[Trailer Trash]

Not true. Many updates are much smaller than the whole package.

Maybe, but most x-code updates that I get are 1GB+.

Re:Not Apple's Fault

[shawn2772]

Not true. Many updates are much smaller than the whole package.

Maybe, but most x-code updates that I get are 1GB+.

So is your argument that Apple is too technically incompetent to deliver single-binary replacements, much less binary patches? Not buying it.

/usr/bin/git *ISN'T* git

[Anonymous Coward]

Why is everyone so focused on replacing /usr/bin/git on their Mac? It's not git. It's just a stub that uses libxcselect to find git within Xcode:

$ otool -L /usr/bin/git /usr/bin/git: /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

If you really want to replace it, replace the one inside of Xcode:

$ xcrun -f git /Applications/Xcode.app/Contents/Developer/usr/bin/git

Or just wait for Apple to release an update with the fix, and go yell at the git developers for completely screwing up the disclosure of this vulnerability, thereby not giving companies time to prepare a release with the fix.

Re:/usr/bin/git *ISN'T* git

[Anonymous Coward]

Or just wait for Apple to release an update with the fix, and go yell at the git developers for completely screwing up the disclosure of this vulnerability, thereby not giving companies time to prepare a release with the fix.

Uh, git is open source software. The git developers released their fix. Are you really suggesting that, since some 3rd parties (Apple in this instance) decided to bundle git with some of their stuff, that git developers can no longer release their software until they've coordinated with every single 3rd party out there? Once git software is released, the bug is essentially disclosed because the source code for the patch is available.

It's not like Apple were caught off guard either. The version of git they're distributing is several major revisions out of date.

Re:/usr/bin/git *ISN'T* git

[Anonymous Coward]

So this git comes with Xcode, right?
Which is not an open-source thingy, but rather a service Apple sells (for free? not sure).
Why do you expect open-source rules to apply, rather than the closed-source ones.
You don't go changing stuff without a reason. And since everyone and their dog uses
homebrew or macports anyways, there is no reason to do this.
Some potentially malicious open-source repos is not sufficient. Its a stupid-user-error if they go and
clone code from a source that might be malicious in the first place. You just don't do such things!

Re:/usr/bin/git *ISN'T* git

[jeremyhu]

Uh, git is open source software. The git developers released their fix.

On March 17. The final Xcode 7.3 seed had already been delivered to developers and was released in the app store two days later.

Are you really suggesting that, since some 3rd parties (Apple in this instance) decided to bundle git with some of their stuff, that git developers can no longer release their software until they've coordinated with every single 3rd party out there?

No, of course not. I'm saying that they should follow good security disclosure practices and coordinate with vendors like other open source projects do. If they're aware of a vulnerability, they should disclose it to vendors (Ubuntu, Fedora, RedHat, FreeBSD, OpenBSD, NetBSD, Oracle, Microsoft, Apple, ...) like other OSS projects do. X11 does this. Other OSS projects do this. Git does not.

The git developers announced this to the world before even they had released a version with the fix even though the fix had been available on master for a few weeks prior. There was no coordination with vendors (or even with themselves).

Once git software is released, the bug is essentially disclosed because the source code for the patch is available.

It's not like Apple were caught off guard either. The version of git they're distributing is several major revisions out of date.

That's not at all true. Apple was definitely caught off guard, as was the rest of the industry. The issue was disclosed 2 days before the fix was released. It was reported to be fixed in a version of git that actually didn't even have the fix.

The version of git that is included on Xcode 7.3 was the latest stable version available when Xcode 7.3 went to beta. git 2.7.0 was released just days before Xcode 7.3.0 beta 1 was seeded to developers, and taking a new major version .0 of git at that time would not be appropriate (given that stability and reliability is a primary concern). The point is to deliver a mature, stable version of git to developers that works well and is well tested with Xcode's IDE SCM and Xcode Server. Users that want the bleeding edge version of git (which updates major versions about every other month) should install it themselves because it's simply not possible to include the latest version at Xcode GM and guarantee a well tested and stable experience to Xcode users.

Re:/usr/bin/git *ISN'T* git

[Anonymous Coward]

Apple could just backport the security fix to their version of Git, just like any Linux distribution does for their stable release (no, they don't usually upgrade to a new stable release).

It's just that Apple doesn't give a shit about security. It would reduce their margins and their user base doesn't care that much about security anyway.

Re:/usr/bin/git *ISN'T* git

[Anonymous Coward]

They wouldn't have had to backport the fix, as it's backported to the 2.6 series I don't know why so many people are talking out of their asses about "bleeding edge". I can only explain it with the reality distortion field causing people to only see the most ridiculous excuses for Apple not shipping a trivial security fix to a single tool for over a month.

Re:/usr/bin/git *ISN'T* git

[jeremyhu]

One difference between Apple's products and Linux distributions is that with distros, you actually get an update to git. With Xcode, you need to get an update to Xcode which contains git. git is used by Xcode for a variety of things and needs to be tested and verified to work correctly with the updated version of git underneath it. It would be bad to fix the vulnerability only to break Xcode's SCM system because of a regression in git.

Quality is a primary concern, and it takes time to test and qualify changes. Many other OSS projects recognize this and have a mailing list to discuss vulnerabilities between developers and vendors ahead of the fix landing and CVE publication. This allows vendors to prepare the fix for their pending releases instead of getting caught off guard by an announcement made at inopportune times that leaves them with no option for shipping a fix and hurting their customers.

Re:/usr/bin/git *ISN'T* git

[Anonymous Coward]

With Xcode, you need to get an update to Xcode which contains git

And that's a fault with Apples distribution system. They need to be able to apply security patches to the dependencies they bundle.

Timmy "I GIT SOM Evah Day"

[Anonymous Coward]

Der Timmy goes a twerking down the street singing "Do wa did e did e dum did e do." He so happy he GIT SOM evah day singing "Do wa did e did e dum did e do."

Ha ha Queers

Simple Fix

[Anonymous Coward]

brew install git
vim ~/.bash_profile
OR whatever text editor you like
Modify your .bash_profile to look like this:

export PATH="/Users/randalls/anaconda/bin:/usr/local/bin:$PATH"

Where /usr/local/bin is BEFORE $PATH, dont forget the colon.

Re:Simple Fix

[Pikoro]

but my name isn't randalls

Re:Simple Fix

[Ash-Fox]

Xcode isn't using it despite the path being set when launching xcode.

10 Places To Buy A Laptop With Linux Preloaded

[Anonymous Coward]

Let me Google that for you: http://www.cyberciti.biz/hardware/laptop-computers-with-linux-installed-or-preloaded/

9 PERCENT love and attention

[Anonymous Coward]

According to MacRumors (and presumably, Apple) and this image:
http://cdn.macrumors.com/article-new/2016/01/piechart.png

Mac Net Sales apparently accounts for just 9 PERCENT of Apple's revenues.

You see that other big slice of Apple pie? The 68 percent? Yeah, that's iPhone. Apple report earnings next week. If enough people weren't dazzled into buying that throwback iPhone 5SE - or new iPhones in general - then Apple stock may start behaving as if it doesn't have Steve Jobs at the helm. I think we have a performance chart for that already.

What does all of this have to do with git on Mac? Well, obviously they'll jump on it now (I would hope) since it's in the spotlight. But you can see why it's possible that your OSX may not be getting the love and attention that you're expecting, or that you've grown accustom to over all of those years and years of loyalty.

Re:9 PERCENT love and attention

[Anonymous Coward]

Or maybe they already jumped on it as soon as it was announced, and it'll be coming out soon in Xcode 7.3.1.

Maybe the reason it wasn't included in Xcode 7.3 was because of the horrific timing of the disclosure to the community and complete lack of disclosure of the vulnerability to companies shipping git.

Re:9 PERCENT love and attention

[Anonymous Coward]

Can I point out that your complaint is this is gits fault for disclosing it when they had a fix for it and that gits release schedule didn't take Apple into consideration. Should Mint bitch about the release timing of Ubuntu? No. If Apple relies on git, then Apple needs to react to git. Period. Apple is not the high and mighty. They are taking something that somebody else produces, they don't pay for it and apparently they don't contribute to it since I'd imagine if they did contribute to it they would have known it was coming. If Apple were a responsible company they would have released a security patch once the patch from git became available. I know you love Apple and you've drank a lot of kool-aid, but git is in no way, shape or form obligated to coordinate with Apple.

Re:9 PERCENT love and attention

[jeremyhu]

Yes, Apple does need to react to git. Apple does that by updating to newer versions of git in newer versions of Xcode.

The issue here was that this announcement was made at a time when it was too late to include in the March 21 release of Xcode 7.3.

> they don't contribute to it since I'd imagine if they did contribute to it they would have known it was coming

Care to elaborate on why you feel that way? Apple has made attempts to contribute to git only to get shot down and rejected in the past, but most of Apple's changes have since been merged into git upstream or are available for anyone that wants to see them on github.

http://marc.info/?l=git&m=126819399002363&w=4
http://marc.info/?l=git&m=129105538829766&w=4
http://marc.info/?l=git&m=137514771912513&w=4
etc...

Re:9 PERCENT love and attention

[Anonymous Coward]

> The issue here was that this announcement was made at a time when it was too late to include in the March 21 release of Xcode 7.3.

So what? "We don't do releases just because of security updates!" or what is the argument here? So if Apple had a release schedule of one Xcode update per year, you'd see nothing wrong with them leaving a security issue open for one year because "it was too late for this year's release"?
If that's the kind of attitude developers have it's no surprise software is full of holes and many companies don't manage to fix security issues ever years after they were reported.

Re:9 PERCENT love and attention

[Plumpaquatsch]

According to MacRumors (and presumably, Apple) and this image: http://cdn.macrumors.com/artic...

Mac Net Sales apparently accounts for just 9 PERCENT of Apple's revenues.

In other words, its Apple's second largest source of revenue, alone bigger than Oracle.

Very Old?

[Anonymous Coward]

git 2.6.4 was released about a month before Xcode 7.3 beta was first seeded to developers. How does "one month old" equate to "very old"?

Do you want Apple to update versions of key components after starting the beta process just because the version number changes? git 2.7.0 came out just days before Xcode 7.3 beta1. It makes sense that they'd stick with 2.6.4 as it was a very stable version and there was no compelling reason to update until just a couple days before Xcode 7.3 was released.

it just works .. sort of that ;)

[Anonymous Coward]

they are all hands on their watch and phones
the sales are abit low this season / year..
maybe they don't have time or lack motivation to fix this issue

I'm macmini user since 2009, iphone / ipad user since 2010 but not for long .. I'm pissed of that Apple-moochie ( long list of poor QA sw in the last years .. ) and switch to linux / ubuntu.

Meanwhile FreeBSD is still awesome

[Anonymous Coward]

distrowatch.com
https://forums.virtualbox.org/

Linux and BSD are there for anybody who thinks pretty homosexual aluminum apple silhouettes or Global Mother Fucking Spyware suck.

https://en.wikipedia.org/wiki/Berkeley_Software_Distribution

brew upgrade git

[richardtallent]

$ git --version
git version 2.6.3
$ brew update
$ brew upgrade git
$ git --version
git version 2.8.1

Back to my

Re:brew upgrade git

[richardtallent]

beer. Back to my beer.

Why do /. comments strip emoticons, especially important ones like beer?

*sigh*

Re:brew upgrade git

[Lennie]

Because Slashdot uses MySQL and their collation doesn't allow it ?

Re:brew upgrade git

[jeremyp]

Because it is shit.

Re:brew upgrade git

[jeremyp]

Clarification: "it" refers to the Slashdot software, not beer, your post or Slashdot the organisation.

Clarification on the clarification: The fact that the clarification states that "it" refers to the software only is not meant to imply that the other things listed are definitely not shit.

Re:brew upgrade git

[s122604]

does not work

Ubuntu 14.10 LTS

[Anonymous Coward]

git 1.9.3

Might be fixed when Xcode is updated in June?

[Sits]

Sounds like this won't be resolved until Apple releases its next Xcode update (or Command Line Tools for Xcode if you aren't using the IDE). Looking at previous release dates it seems that Apple releases new versions every three months and the previous version was released 21st of March 2016.

Re:Ahahahahaha

[lucm]

iApologist much?

Re: Sunds pretty fishy

[ArsenneLupin]

[not the original poster, just normal reading comprehension...]
(Probably) what he means is "Apple doesn't support more than 3 buttons on mice, unless it's their own overpriced $75 "magic mouse". Button 4 and 5 could be used (for example) for back and forward in a browser"
(Didn't even know that Macs support mice with more than one button, hehe, so 3 is already a neat progress...)

Re: Sunds pretty fishy

[Anonymous Coward]

Try BetterTouchTool. It's a boss for mice and more.

I Use SourceTree

[Anonymous Coward]

Atlassian SourceTree isn't the greatest thing on earth, but it is parsecs better than the Xcode crap.

It also bundles a newer version of Git than the Mac (not 2.8, yet, but currently 2.7.4).

I work on a Mac in half a dozen languages and environments, so SourceTree gives me what I need to manage my repos.

Re: Sunds pretty fishy

[Aaden42]

Umm. . . USBOverdrive? Works nicely on El Capitan. All 8 buttons on my Logitech are mapped to useful functions.

Even the stock MS & Logitech drivers let you remap the extra buttons if you don’t want to shell out the $20 for USBOverdrive. USBOverdrive lets you setup keyboard & mouse macros per-application which can come in handy.

Re: Sunds pretty fishy

[macwhiz]

Macs have natively supported two- and three-button mice since Mac OS 8 in 1997. Mice with additional buttons work fine provided you have an appropriate driver for them, just like on Windows. If the manufacturer doesn't supply a driver for their extra buttons, there's third-party drivers that work with any USB HID compliant mouse. Logitech gaming mice, with all their buttons, work just fine on Mac OS X. Your troll is out of date...

Re: Sunds pretty fishy

[ArsenneLupin]

Drivers... But what if some "punk" feature on your Mac prevents you from installing any drivers not blessed by Apple?

Re: Sunds pretty fishy

[Khyber]

"Mice with additional buttons work fine provided you have an appropriate driver for them, just like on Windows."

I don't even need drivers in Windows. Yay fucking STANDARDS. Oh, Apple's never heard of those.

Re: Sunds pretty fishy

[macwhiz]

What, you mean the USB HID standard that defines two axes of movement (X and Y) and three buttons? Or the Microsoft convention that certain buttons, on certain mice, should be mapped to forward and back—there being no actual standard for which USB HID button numbers should be mapped to those functions?

Apple builds themselves a walled garden

[ComputerGeek01]

Apple builds themselves a walled garden, then utterly failed to prevent a fire from breaking out on the inside. This my friends is sweet poetic justice. A modern OS cannot exist in isolation like these hipster wannabes like to think it can. Apple is not omnipotent and it does not know what is best for you. Every informed Mac user I have ever met bought their system for the same reason, they don't want to take responsibility for their own security. Well guess what, that isn't possible and it never actually was.

Re:Apple builds themselves a walled garden

[Anonymous Coward]

A modern OS cannot exist in isolation

Put the bong down, now what does that even mean?

Re:Ahahahahaha

[Anonymous Coward]

Windows / Linux don't have security issues, and never have

I can very, very easily upgrade git on these operating systems, all by myself and without waiting on the OS vendor...

Apple is proprietary crap

[Anonymous Coward]

Get a real os, Linux rules!

Re:Ahahahahaha

[Anonymous Coward]

GNUApologist much?

FTFY

"very old" ?

[Anonymous Coward]

Only in Internet parlance would something released 4 months ago be considered "very" old. There's literally a billion Android devices in the world that are susceptible to equal (and easier) attacks that are running software that is *years old* and will never be patched.

sitcom sports closet

[epine]

As I expected, spending 5 minutes typing a simple example to make a point brought the insecure people out of the woodwork.

I take it you're from planet Seinfeld, where even what you manage to learn about life (generally frowned upon) does basically nothing to change your behaviour. In your haste to hew to "simplicity", one large worm MIRVed into multiple smaller worms, and you basically went (inside your own mind) "and the rest is fine print", without a whit of that thought making it to your fingers (heaven forbid that your 5m effort turn into a 5m30s effort).

Technical debt, meet treading-lightly-upon-the-fine-print debt. Back in the seventies, never a closet door was opened on a sitcom without twenty pounds of unused sports equipment cascading down from the storage shelf. And yet, in at least 50% of the buying public, a giant "on sale" tag attached to a racket handle still succeeded in disabling the part of the brain chanting quietly to itself "and where would I put it?"

Some people by nature tend to read the fine print. I'm one of those people, so I know how it goes. It's all too easy to slide into an enabling role, where half your day is spent—for little official credit—helping extract fine-print avoiders from the sports-sock snow pack when the karma closet finally comes tumbling down.

"Gosh, I had no idea snow could be so heavy."

"Would you like some rum with that? I've got this keg thing around my neck."

"I thought those were mechanical gills."

"No, the sound effects are made by a Raspberry Pi. It's actually a keg of rum."

"Wow, you're awfully prepared. I take it you do these rescues a lot?"

"Enough to learn how the pattern goes a hundred times over."

"How does it go?"

"Here's where it starts. Someone tosses off a quick 5m answer, without even noting that fine print exists, even if it only takes an extra ten words."

"But everyone knows that fine print exists."

"To judge by the state of your closet, you're a lapsed Catholic and I'm your indulgence."

"You sound bitter."

"Just a minor side effect of my cellulose diet."

Re:Ahahahahaha

[Anonymous Coward]

Windows / Linux don't have security issues, and never have

I can very, very easily upgrade git on these operating systems, all by myself and without waiting on the OS vendor...

And yet you are too dumb to do it on a Mac - which makes you a computer expert. Impressive.

Security and Usability are always opposed

[Anonymous Coward]

The most secure system is one with no inputs or outputs, and preferably no execution as well.

You are technically retarded. If you don't need ultra high security, don't use it. Don't pretend that there is no one who needs that level of security, or that there is some magic security mechanism you can apply which prevents malicious actions without impacting the user.

Solaris RBAC / Shutdown

[Tenebrousedge]

Depending on what you mean by "clean shutdown", you should just have to do some RBAC setup:

Edit /etc/security/exec_attr and add the following profile:
exec_attr:Shutdown:suser:cmd:::/usr/sbin/shutdown:uid=0;gid=1

Add this profile to /etc/user_attr
yourusername :::: profiles=Shutdown

Then your user can shutdown with /usr/bin/pfexec /usr/sbin/shutdown

Instructions taken from here.

As to the more general topic, all major OSes operate on the "Principle of Least Privilege", which in this case means discouraging casual use of the superuser account, or disabling it entirely. With apologies to Twain, "Suppose you were logged in as root all the time, and suppose you were an idiot. But, I repeat myself."

Re:Solaris RBAC / Shutdown

[Guy Harris]

Depending on what you mean by "clean shutdown", you should just have to do some RBAC setup:

Edit /etc/security/exec_attr and add the following profile: exec_attr:Shutdown:suser:cmd:::/usr/sbin/shutdown:uid=0;gid=1

Add this profile to /etc/user_attr yourusername :::: profiles=Shutdown

Then your user can shutdown with /usr/bin/pfexec /usr/sbin/shutdown

In this particular case, I am the user in question, and I'm lazy enough that I'd prefer to do it from the GUI as I can in Windows and OS X and Ubuntu and Fedora, for example.

Oh, and I can shut down as non-root from the GUI on Solaris 11, too.

(Not that I'm running Solaris 10 much these days; not much platform-specific libpcap/tcpdump/Wireshark development needed there.)

As to the more general topic, all major OSes operate on the "Principle of Least Privilege", which in this case means discouraging casual use of the superuser account, or disabling it entirely. With apologies to Twain, "Suppose you were logged in as root all the time, and suppose you were an idiot. But, I repeat myself."

+1

Re:Solaris RBAC / Shutdown

[Tenebrousedge]

...I'd prefer to do it from the GUI as I can in Windows and OS X and Ubuntu and Fedora...

The link I gave above gives instructions on how to do that. It requires that you use gdm as your display manager, though. I wasn't able to find any other way to do that, but on the plus side now I have a Solaris VM to play with. I should note that I have no experience with Solaris whatsoever, and only had the article I linked to hand because someone mentioned this shutdown issue in another discussion this week. I'm still sort of incredulous that this kind of UI issue would even arise, but I'm glad they fixed it eventually.

Already fixed in Xcode 7.3.1

[jeremyhu]

FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.

Re:Already fixed in Xcode 7.3.1

[Guy Harris]

FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.

(Presumably "git 2.7.4".)

Re:Already fixed in Xcode 7.3.1

[Anonymous Coward]

> FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.

I'd be surprised if 7.3.1 didn't contain every free software package ever released.

It took me over 2 hours to download and install 7.3.

To quote Parker, "the son of a bitch was HUGE!!"

Re:Already fixed in Xcode 7.3.1

[jeremyhu]

LOL, yes sorry for the typo. I meant 2.7.4.

Re:Already fixed in Xcode 7.3.1

[jeremyhu]

Well it basically contains 3 full operating systems (watchOS, tvOS, and iOS runtimes).

=/

Just use homebrew

[etinin]

Most decent programmers wil have updated their machine's git version using Homebrew. People who are not capable of doing it, probably won't even be using git in the first place. Also, it's possible to disable Apple's system protection by booting into recovery mode and running one or two commanda, thus giving root it's standard UNIX prerrogatives. Many users, myself included, choose to do this.

Re: Sunds pretty fishy

[Khyber]

"What, you mean the USB HID standard that defines two axes of movement (X and Y) and three buttons?"

Care to point out where it's limited to three buttons? Because my little cheap no-brand 7 button mouse from China has all buttons recognized, no drivers. Perhaps if you understood that the interface standard allows for having the report descriptor changed to show more buttons being present via the mouse firmware (and has been since.. 2001 at least) you might not have made such a crucial mistake.

Very Old?!

[artlogic]

Since when does "very old" qualify as an accurate description of a release that occurred just over 4 months ago? While I believe Apple should fix this (and it shouldn't really be that hard), I think it's a bit disingenuous to characterize what they distributed this way. Especially when Debian is still distributing (patched) 2.1.4!

Re: Sunds pretty fishy

[Plumpaquatsch]

"Mice with additional buttons work fine provided you have an appropriate driver for them, just like on Windows."

I don't even need drivers in Windows.

You probably haven't notice that Windows tends to actually installs drivers from the net every other time you plug in a more-than-three-button mouse. At least when moving between docking stations at work it does. And that's when it actually detects USB mouse and keyboard for a change.