Rogue Source Code Repos Can Compromise Mac Security Due To Old Git Version (softpedia.com) 184
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."
Compile and path (Score:3, Interesting)
Re:Compile and path (Score:5, Informative)
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 (Score:4, Informative)
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: (Score:3)
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 (Score:4, Informative)
~/.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: (Score:2, Informative)
You can also update the system path with the following and reboot.
Re: (Score:1)
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: (Score:3)
Changing the path with launchctl is not one of them.
Re: (Score:2)
Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?
Well, you definitely should not be surprised. [0pointer.de]
(I.e., Lennart likes the idea of launchd.)
Re: (Score:2)
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.
Re: (Score:3)
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: (Score:3)
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.... [cisecurity.org]
There comes a point where hackers cause less damage than this kind of "security".
macports (Score:2, Insightful)
Not that complicated.
It's Impossible!!! (Score:5, Informative)
sudo port install git
echo "export PATH=/opt/local/bin:\$PATH" >> ~/.bashrc
Oh! The humanity!
(Requires https://www.macports.org/insta... [macports.org])
As an aside, it's possible to override SIP, but it's a bit of a PITA.
Re:It's Impossible!!! (Score:5, Informative)
Yup, boy howdy that was hard.
$ git --version
git version 2.6.4 (Apple Git-63)
$ fink install git
$ hash -r
$ which 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: (Score:3)
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: (Score:1)
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.
Re: (Score:1)
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: (Score:2)
Oh, how droll. You assume /.-ers are imbeciles incapable of handling the command line.
Re: (Score:2)
Most current /.ers certainly can't handle the command line. They were born in the age of the GUI.
How thoughtless of you.
Re: (Score:2)
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: (Score:2)
As I expected, spending 5 minutes typing a simple example to make a point brought the insecure people out of the woodwork.
sitcom sports closet (Score:2)
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
Yes, you *can* replace /usr/bin/git (Score:5, Informative)
First, you turn off System Integrity Protection by following the directions on Apple's Configuring System Integrity Protection [apple.com] 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: (Score:1)
Re:Yes, you *can* replace /usr/bin/git (Score:5, Insightful)
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: (Score:3)
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
Re: (Score:2)
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
Re: (Score:3)
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: (Score:2, Insightful)
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: (Score:2)
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 en
Re: Yes, you *can* replace /usr/bin/git (Score:3)
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 pack
Re: (Score:2)
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 mai
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
"Fail and fail" is generally considered to be uncomplimentary. Just FYI.
And you consider that bashing? Have you been raised by hippies?
Re: (Score:2)
I'm not sure what hippies are, so I doubt it, but I do understand what politeness and manners (and their opposites) are.
Re: (Score:2)
Re: (Score:2)
You should. She apparently already installed Xcode and is forking various git repos.
Re: (Score:2)
...just as soon as you finish training her to use version control.
Re: Yes, you *can* replace /usr/bin/git (Score:4, Insightful)
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.
Solaris RBAC / Shutdown (Score:3)
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 :::: profiles=Shutdown
yourusername
Then your user can shutdown with /usr/bin/pfexec /usr/sbin/shutdown
Instructions taken from here [oracle.com].
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: (Score:2)
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: (Score:2)
...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 fix
Re: (Score:2)
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: (Score:2)
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 [microsoft.com], Windows Resource Protection [microsoft.com] (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:
Re: (Score:2)
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 yo
Forking is for GitHub (Score:1)
When you make a copy of a git repository on your machine, it's called "cloning" the repo. "Fork" is a GitHub buzzword.
Re: (Score:3)
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.
Very old? (Score:1)
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: (Score:1)
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'
Re: (Score:2)
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: (Score:1)
> 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
Re: (Score:2)
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
She's Assuming Naive Devs, Then (Score:2)
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: (Score:3)
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 (Score:4, Informative)
Might be fixed when Xcode is updated in June? (Score:1)
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: (Score:2)
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 di
Let me get this straight... (Score:2)
Does this mean that if your hardware vendor has a deity level above root then that is a bad thing?
Simple fix to old rogue source code issue (Score:5, Funny)
Re: (Score:2, Funny)
You made my day. Here, have a dog.
d
Not Apple's Fault (Score:5, Informative)
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 (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
That's how Apple do.
Re: (Score:2)
Re: (Score:2)
Not true. Many updates are much smaller than the whole package.
Maybe, but most x-code updates that I get are 1GB+.
Re: (Score:2)
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 (Score:4, Informative)
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: (Score:2)
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.
Re: (Score:2)
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 ch
Very Old? (Score:1)
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.
Re:Very Old? (Score:4, Informative)
It's an apple hate story that actually is devoid of anything useful.
brew upgrade git (Score:2)
$ git --version
git version 2.6.3
$ brew update
$ brew upgrade git
$ git --version
git version 2.8.1
Back to my
Re: (Score:1)
beer. Back to my beer.
Why do /. comments strip emoticons, especially important ones like beer?
*sigh*
Re: (Score:2)
Because Slashdot uses MySQL and their collation doesn't allow it ?
Re: (Score:2)
Because it is shit.
Re: (Score:2)
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: (Score:2)
Apple builds themselves a walled garden (Score:2)
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 w
Already fixed in Xcode 7.3.1 (Score:1)
FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.
Re: (Score:2)
FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.
(Presumably "git 2.7.4".)
Re: (Score:2)
but my name isn't randalls
Re: (Score:3)
Re: (Score:1)
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: (Score:1)
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 o
Re: (Score:2)
According to MacRumors (and presumably, Apple) and this image: http://cdn.macrumors.com/artic... [macrumors.com]
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.
Re: (Score:2)
iApologist much?
Re: (Score:2)
Umm. . . USBOverdrive [slashdot.org]? 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: (Score:2, Interesting)
(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: (Score:2)
Re: (Score:2)
Re: (Score:1)
"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: (Score:3)
Re: (Score:2)
"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.
Re: (Score:2)
"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.
Re: (Score:1)