So while Apple has patched bash, this version of the shell is simply ancient. Just how old is it? bash 3.2.53(1) is roughly seven years behind the current version, 4.3.25. Seven years is like, well, forever, in Internet time!
With that bash age gap in mind, I took at look at a number of common Unix apps—in both Mavericks and Yosemite—to see which versions were in use. Then I checked the same apps in MacPorts, a tool that makes it simple to install many Unix apps.
(MacPorts doesn’t necessarily have the absolute latest version of every Unix app, but they do stay relatively current. For instance, they already have a patched version of bash that fixes the above vulnerability.)
The results were interesting, to say the least—many of the core Unix utilities in OS X are years and multiple versions behind their open source, er, sources. You can thank GPL v3 for that, as noted above (and covered in more detail below). But that still leaves the big question:
That is, should we care that these tools aren’t keeping up with their latest and (presumably) greatest versions? Is it a problem, or merely a statement that what we have works well enough for the majority of users? (For those who don’t want to bother reading, my general opinion is no, it doesn’t matter.)
|Tool||Curr. License||Version||© Date||Version||© Date||Version||© Date|
|curl||MIT/X||7.30||Apr 12 ’13||7.37.1||Jul 16 ’14||7.38||Sep 10 ’14|
|May 9 ’14||188.8.131.52
|Jul 22 ’13||2.1.0||Aug 15 ’14|
|grep||GPL v3||2.5.1||Oct 29 ’04||2.5.1||Oct 29 ’04||2.20||Jun 3 ’14|
|nano||GPL v3||2.0.6||Aug 24 ’13||2.0.6||Aug 24 ’13||2.2.6||Nov 26 ’13|
|openssl||Apache||0.9.8za||Jun 5 ’14||0.9.8za||Jun 5 ’14||1.0.1i||Aug 6 ’14|
|php||PHP||5.4.30||Jul 29 ’14||5.5.14||Aug 30 ’14||5.6.0||Aug 31 ’14|
|sqlite3||Public Domain||3.7.13||Jul 17 ’12||3.8.5||Aug 15 ’14||3.8.6||Aug 15 ’14|
|ssh||BSD||6.2p2||8 Dec ’11||6.2p2||8 Dec ’11||6.6.1p1||6 Aug ’14|
|sudo||ISC||1.7.10p7||Feb 27 ’13||1.7.10p7||Feb 27 ’13||1.8.8||Sep 29 ’13|
|tcsh||BSD||6.17.00||Jul 10 ’09||6.17.00||Jul 10 ’09||6.18.01||Feb 14 ’12|
|vi/vim||BSD||7.3||Aug 15 ’10||7.3||Aug 15 ’10||7.4||10 Aug ’13|
|zsh||MIT||5.0.2||Dec 21 ’12||5.0.5||Jan 6 ’14||5.0.6||Aug 29 ’14|
|Links to license definitions: Apache • Artistic • BSD • GPL v2 • GPL v3 • ISC • MIT/X • PHP • Public Domain|
(Highlighted entries reflect tools that are getting updates in Yosemite.)
As you can see, most versions of the Apple-supplied tools are far behind the MacPorts versions (and some of those might even be older than current versions).
The question I have, and that I’m not sure who at Apple might be willing or able to answer it, is this:
Are those versions really as old as they appear, or have some fixes and/or features been backported into older version numbers?
I know in at least one case that fixes have been backported: openssl 0.9.8za is not a “real” release, but one created by Apple (and released in OS X 10.9.5) that contains fixes for a number of CVEs (2014-0076, 2014-195, 2014-0221, 2014-0224, and 2014-3470). So openssl clearly gets some backported security updates.
But what about the other apps? Just looking at version numbers, I suspect that bash may also have such backported fixes—its version number is not identical in structure to the official release on MacPorts. But that leaves a huge number of tools that are simply old, apparently lacking both security and feature updates. And old is really old in many cases. Here’s what that means for a few key tools I rely on.
As noted earlier, OS X uses a very old version of bash—seven years older than the current release, and four years older than the release of bash 4.0. That release was a big one, with a huge number of changes and improvements.
As but one example, consider the help output for bash commands such as cd, history, etc. Here’s what help dirs displays in the OS X version of bash:
$ help dirs dirs: dirs [-clpv] [+N] [-N] Display the list of currently remembered directories. Directories find their way onto the list with the `pushd' command; you can get back up through the list with the `popd' command. The -l flag specifies that `dirs' should not print shorthand versions of directories which are relative to your home directory. This means that `~/bin' might be displayed as `/homes/bfox/bin'. The -v flag causes `dirs' to print the directory stack with one entry per line, prepending the directory name with its position in the stack. The -p flag does the same thing, but the stack position is not prepended. The -c flag clears the directory stack by deleting all of the elements. +N displays the Nth entry counting from the left of the list shown by dirs when invoked without options, starting with zero. -N displays the Nth entry counting from the right of the list shown by dirs when invoked without options, starting with zero.
And here’s how it displays in the MacPorts version of bash:
$ help dirs dirs: dirs [-clpv] [+N] [-N] Display directory stack. Display the list of currently remembered directories. Directories find their way onto the list with the `pushd' command; you can get back up through the list with the `popd' command. Options: -c clear the directory stack by deleting all of the elements -l do not print tilde-prefixed versions of directories relative to your home directory -p print the directory stack with one entry per line -v print the directory stack with one entry per line prefixed with its position in the stack Arguments: +N Displays the Nth entry counting from the left of the list shown by dirs when invoked without options, starting with zero. -N Displays the Nth entry counting from the right of the list shown by dirs when invoked without options, starting with zero. Exit Status: Returns success unless an invalid option is supplied or an error occurs.
There’s no functional difference between the two dirs commands in terms of options, but the command’s help is much easier to read in the newer version of bash. I may not use help much, but when I do, it’s nice to have a well-formatted page to read.
The problem with updating bash yourself is that it’s tied into the lowest levels of OS X. So while MacPorts makes it easy to install and run a newer version of bash for your own scripts, system-provided scripts and processes will still call the old bash. I’ve actually replaced all versions of bash, as I described yesterday, which is potentially very dangerous. So far, though, things are working normally.
I would expect Apple to patch the security hole in bash, but not to do so by giving us a 4.x version to install.
For those not familiar, git is a version control system; I don’t use it myself, but know quite a few people who do. I bring it up here not because it’s out of date (it’s not), but because it’s taking a step backwards in Yosemite. As of today, at least, the version of git in the latest developer preview is actually older than the version we have in Mavericks. (Note that Apple apparently ships a customized version of git, based on the Apple Git-50 designation in the version number.) I assume this is a temporary issue, and we’ll see an updated version when Yosemite ships.
I use rsync a lot—it’s an incredibly useful command line tool for syncing files across hard drives and to/from remote systems. I rely on it for my multi-drive, multi-site backup system. Version 2.6.9 (the current OS X version) was released in 2006—over eight years ago! The next version after 2.6.9 was 3.0, and it was released in 2008! Apple is over six years behind on the major version upgrade, and a further 10 updates have come out since 3.0; MacPorts is current at version 3.1.1.
There are a lot of new features in the rsync 3 release, many of which make the tool run faster and preserve more file data than its predecessor. So why hasn’t OS X kept up with this release? Perhaps Disk Utility uses rsync in some manner? But if not, then why is it languishing? I’ve personally switched to the MacPorts installation, and have not had any issues with it.
Personally, I’m a BBEdit or vi guy, but I know a lot of folks who love and rely on emacs. The OS X version is seven years—and nine releases—from current. Tons of new features and bug fixes in those releases, including better Unicode support, along with some security patches. Does the OS X emacs have the security fixes? I have no idea, and I’m not sure how to tell. As best I can tell, emacs is a standalone tool (not integrated into any core OS X features), so why hasn’t Apple given us a newer version in seven years?
Apple uses sqlite for a number of database tasks, such as tracking Mail messages. Given how well it’s tied into the system, perhaps it’s not surprising that it’s fallen behind the official releases. What is surprising is just how far behind it is—a full 22 releases since it was last updated. But then again, perhaps this is “if it’s not broke, and we rely on it, don’t fix it.”
The good news is that sqlite3 is getting an update to nearly-current status in Yosemite.
This one surprises me—given how important security is in the remote connectivity services provided by openssh, I figured Apple would keep this one current. But unless they’re hiding backported fixes in old version numbers, the stock version of ssh is roughly three years old, missing four fairly major updates (6.3, 6.4, 6.5, 6.6).
Are we really relying on an out-of-date version of ssh lacking key security updates? I’ve emailed Apple Security, asking if they can share anything about how they update ssh, but I’m not really expecting a response.
While sudo looks quite out of date, it’s not quite as bad as it appears. That’s because the 1.7 branch is the maintenance branch, which receives no new features, just bug fixes. Within the maintenance branch, there’s only one newer release, 1.7.10p8. That release contains one security bug fix, though it doesn’t appear to be a serious hole.
Those in search of new sudo features (is there a large number of such people?) can use MacPorts to install versions in the “current” 1.8.x tree, which does get new features.
The GNU GPL
Thanks Geordie Korper for commenting on the obvious, which I completely overlooked in my original posting: the likely cause of the aging code base is the GNU General Public License version 3. This is a new version of the license—released in June of 2007—that governs many open source apps.
As noted at the beginning of the article, it’s clearly GPL v3 that’s preventing many of these tools from being updated. Exactly what it is about the v3 license that scares Apple away? I’m not sure; some web searching seems to indicate that it might be related to the patente language in v3, which is there as a direct result of a Microsoft-Novell deal.
But who knows for sure…whatever the reason, Apple feels it can’t legally include GPL v3 apps with OS X any more. And that’s a shame, because some of these apps are very good. Thankfully, you can install newer versions yourself, with nothing more than some clicks and a bit of typing. How?
You can install newer versions of the above tools (and many other apps) via an OS X package manager. There are many to choose from; I personally use MacPorts, but there’s also Fink and Homebrew. Pick the one that works best for you, and you don’t have to live with Apple’s ancient tools. These package managers not only make it easy to get new versions, they also keep them separate from the OS X versions, so as to not cause issues down the road.
Wrapping it all up
So back to the big question: Does it matter?
Generalizing, I’m of the opinion it doesn’t really matter. Most OS X users never venture near the command line, so the age of the bundled tools won’t make any difference to them. As long as the GUI side of the OS does what they want, they’ll be happy.
Taking off the generalist’s hat, I’m curious as to how Apple handles security fixes for the older versions of these tools. If they’re backporting them into the current release, but keeping the version number the same, that’s a dangerous path to follow. (See how well that worked for GM?) Still, backporting means we at least have the security fixes; if they’re not patching the releases, it’s not good news. Maybe some day we’ll see a version of the GPL that Apple can live with, but I doubt it—Apple is not exactly a poster child for the Free Software Foundation’s mission.