In regards to the glibc gethostbyname buffer overflow, some thoughts on release schedules and long term support. Per the advisory, this was fixed in 2013. The commit was May 21 and the release August 12. Sourceware git says the patch itself was authored as far back as January 21.

After the bug was fixed, it took some time for the new glibc release to trickle down into various Linux distros. But what takes even longer is for all the already shipped and supported versions to slowly cycle out of their maintenance window. Hence, the big rush to patch today.

In theory, somebody at glibc should have noticed that fixing a buffer flow in a function that parses network data has security implications. That doesn’t always happen, however, for many reasons. Sometimes the assessment isn’t made; sometimes the assessment fails to consider all possible exploit strategies. Security bugs are “silently” fixed frequently enough (without evil intentions) that we should consider them a fact of life and deal with them accordingly.

One strategy is to minimize the amount of time old, unfixed code remains in the wild. Old releases should be expired, not supported.

The OpenBSD project releases a new version twice per year, every six months. The past two releases are supported, in the sense that they get patches and developers are generally willing to answer questions and investigate bug reports. Past that, all inquiries get the same answer. “Upgrade to a newer release.”

What this means is that the oldest supported OpenBSD release is never more than one year old. All the bugs that were fixed (security, reliability, otherwise) but not immediately identified as high impact get flushed out of the ecosystem after one year. There can be latent two year old bugs, but there can’t be latent fixed two year bugs. Optimistically, users upgrade every release, meaning fixes go from patches in cvs to code on users’ machines within six months.

Now on the one hand, this forces users to upgrade at least once per year. On the other hand, this forces users to upgrade at least once per year. Upgrades only get harder and more painful (and more fragile) the longer one goes between them. More changes, more damage. Frequent upgrades amortize the cost and ensure that regressions are caught early. No one upgrade is likely to end in disaster because there simply isn’t enough change for that to happen.

Nothing kills a bug report faster than “My network card worked in 4.4 but stopped working in 5.6.” Developers aren’t going to bisect five years of changes; you get to do that yourself. Reviewing six months of changes is a much less demanding request. It’s also simple enough that many times users can pinpoint the offending commit themselves because there’s so much less code to review.

OpenBSD has adopted this support strategy because pragmatically, backporting fixes is simply too much work. However, it’s not just about doing less work; it’s about creating less work. The less time old broken code is out there, the less likely users are to encounter it and file bug reports. Sifting through bug reports to determine if they’re still relevant is also a lot of work. The best bug reports are the ones you don’t get.

A one year support window isn’t too short; it’s too long.

updates

I didn’t directly address the possibility that upgrades bring more new bugs than they fix. Implicit is the assumption that the upgrade will inevitably happen. Long term support is not forever support. Given that, sooner is better than later. Better than never...?

Yes, OpenBSD changes things. pf.conf will change. Then time_t will change. Then apache will change. I’d rather handle those changes one at a time than all at once.

Counterpoints:

What the GHOST tells us about free software vulnerability management

The main thrust of my argument is that even if all the vendors got together and figured out communications, they would still miss things.

The practical result of OpenBSD’s support policy

I think it’s better for users to be aware that they have been marooned, rather than to give them empty promises that all the important fixes will be backported.