Monday, November 26, 2007

Apple Software Build Numbers

Paul Suh, from ps-enable.com writes the following:

Have you ever wondered what the build numbers mean for Apple software? (Click on Version to get to Build to get to Serial Number then back to Version)



For instance, Mac OS X 10.4.10 Intel is build 8R2232. Mac OS X Server 10.4.11 Universal is 8S2169. These numbers have the following rough meanings:

8 - This is the major version number of the software package. 10.5 = 9, 10.4 = 8, ... 10.0 = 4. Prior to that was NextStep 3.3, from which we get the 3 series.

R - This is the minor version number. It is always incremented for system updates (i.e. 10.4.10 to 10.4.11 is always a letter jump), but may be incremented as well for hardware-specific builds. R is the 18th letter, but only the 10th update to Tiger. The other 8 letter bumps were for hardware support for new releases. Security updates generally don't merit a letter bump.

2232 - This is the sequential build number within the minor version. If it is a four-digit number, the first digit indicates a specific platform. In this case, 2 indicates that it is for Intel. A three-digit or shorter number indicates a unified build for all architectures. The remaining digits are the sequential build number. In this case, the R train had 232 builds before release, the first one being build 8R2001. Although the builds are roughly daily, you can't really go by that number. In the early stages builds may only happen once every two or three days; towards the end they may occur two or three times a day. The build trains of successive releases may overlap to a certain extent, based on what Apple Engineering sees as the priority vs. risk of various changes to the code. The earliest builds of 10.4.11 almost certainly overlapped with the last builds of 10.4.10. The builds of Leopard definitely overlapped with builds of Tiger updates, going back to almost all the way to the day after Tiger was released.

Note that different software packages have totally different build numbers, so you can't compare the build numbers to each other in a meaningful way. The exception is that Mac OS X and Mac OS X Server share the same build numbers.

Wednesday, November 21, 2007

Christmas in Southern California

How do you know when it's Christmas in Southern California?
Starbucks switches from white to red coffee cups.

Sunday, November 11, 2007

What is the deal with Asian hacking?

The hardware firewall on my mother's network was having a problem so I had her plug her computer straight into the cable modem. I realized that this isn't the best idea, but it's a Mac, so the only way someone could get in is if they guessed her username and password which were both strong.

However, I was alarmed when I took a peek at her security logs (/var/log/secure.log) to see so many attacks over SSH - primarily from from Asia (China, Korea, and India). Here's a small sample:

Nov 10 13:57:27 MacBook-Pro sshd[11704]: Invalid user admin from 208.51.155.141
Nov 10 13:57:28 MacBook-Pro sshd[11706]: Invalid user test from 208.51.155.141
Nov 10 13:57:29 MacBook-Pro sshd[11708]: Invalid user imaging from 208.51.155.141
Nov 10 13:57:31 MacBook-Pro sshd[11710]: Invalid user oracle from 208.51.155.141
Nov 10 19:20:41 MacBook-Pro sshd[12097]: Invalid user test from 218.1.65.233
Nov 10 19:20:45 MacBook-Pro sshd[12099]: Invalid user guest from 218.1.65.233
Nov 10 19:20:49 MacBook-Pro sshd[12101]: Invalid user admin from 218.1.65.233
Nov 10 19:20:53 MacBook-Pro sshd[12103]: Invalid user admin from 218.1.65.233
Nov 10 19:20:57 MacBook-Pro sshd[12105]: Invalid user user from 218.1.65.233
Nov 10 19:21:13 MacBook-Pro sshd[12116]: Invalid user test from 218.1.65.233
Nov 10 20:23:04 MacBook-Pro sshd[12152]: Invalid user apple from 125.16.216.69
Nov 10 20:23:09 MacBook-Pro sshd[12157]: Invalid user brian from 125.16.216.69
Nov 10 20:23:15 MacBook-Pro sshd[12162]: Invalid user andrew from 125.16.216.69
Nov 10 20:23:20 MacBook-Pro sshd[12167]: Invalid user newsroom from 125.16.216.69


Each attack would last between five and 20 minutes and they'd all go for the low hanging fruit such as common usernames and passwords. One solution is to simply change the SSH port from 22 to an obscure port.

I'll be keeping a close eye on those logs.