Security Updates

We’ll be talking a lot about “security updates” on the blog, so a word about what these are and how we handle them is probably in order.

There are literally thousands of software programs on our servers, most of which are written by other people and used by many companies. From time to time, “security vulnerabilities” with these kinds of programs are discovered. A security vulnerability is something that could allow a “hacker” (or “cracker”, for purists, although that battle has been lost) to take advantage of a programming bug to do something unauthorized with the program, such as send spam or delete files.

When one of these flaws is identified, the author of the program (or perhaps someone else) will fix the bug and distribute an update. Obviously, it’s important for anyone running a server on the Internet to keep up with those fixes. This is one reason why running a Web server yourself is hard work.

We couldn’t possibly hope to keep up with the updates to thousands of programs all by ourselves. Instead we get our programs from a “Linux distribution” — a collection of programs maintained and distributed by another organization (Debian Linux in our case).

The fine folks at Debian provide (among other choices) a “stable” set of programs. Whenever one of the stable programs is found to have a security problem, the Debian folks modify the stable version to fix the security problem without changing anything else. This is called “backporting” the fix. They try very hard to avoid changing other parts of the program, even if the author also added buggy new features as part of the update.

This keeps our systems stable: we’re constantly updating our software to fix security problems, but we don’t want to add new features as part of that, because new features tend to cause new problems. If we were upgrading to the full latest version of every program all the time, we’d be constantly introducing new problems into our systems, and you quite rightly wouldn’t like that at all. We install feature updates much less often, and only after lots of testing.

This has a couple of effects. First of all, even if it looks like we’re not using the very latest version of a program, we’re almost certainly using the security fixes from that version. An example is PHP 4; at the time I write this, we offer PHP 4.3.10 — but the version we’re using actually has security fixes from versions through 4.4.7, even if it doesn’t have the new features from those later versions.

Secondly, for the most part, when we announce a “security upgrade” here, you don’t have to worry that the update contains any major changes that might break your scripts on your site. It should just keep right on working as before, but without the potential security vulnerability. If something that used to work stopped working as a result of a security update, we’d consider that a serious issue to be fixed immediately. Fortunately, those kinds of problems are rare.