Delays in security updates [LWN.net]

July 20, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

There are a number of reasons that users choose Linux, but security is one of the most often-cited reasons. While Linux distributions certainly see their fair share of security issues, updates are usually issued in a timely fashion.

However, there are times when the process gets bogged down. Security updates for Debian, for example, were not going out in a timely fashion for some time. As reported in Branden Robinson's Debian Project Leader Report for July, security updates were interrupted for some time. This has also been reported in the mainstream press, though members of the Debian team take issue with the actual reporting.

Looking at the security advisories for 2005, one thing that is clear is that no security updates were issued through most of June. There are no updates from June 4 through June 29. Updates resumed on June 30, and there have been a steady stream of updates since then. We e-mailed Martin Schulze about the Debian security delays, and he confirmed the time period.

That is quite a delay for some of the updates. For example, the sudo vulnerability, for example, was addressed in Debian on July 1 for Woody and Sarge. The Fedora Core team released an update for this vulnerability for Fedora Core 3 and Fedora Core 4 on June 21, and Ubuntu released an update on June 21st for Hoary (5.04) and Warty (4.10). Updates for Gaim's recent vulnerabilities were issued on June 16 for FC3 and FC4, and June 10 and June 15 by the Ubuntu team, respectively -- but not for Debian until July 5.

In an e-mail, Schulze said that he didn't know all of the details of the problems that delayed updates, but explained way the process is supposed to work:

When a new release happens the old release, formerly known as "stable", becomes "oldstable" and "testing" becomes "stable."

This change needs to be done on the ftp-master, on the security host and on the wanna-build database (the database behind the buildd network).

In addition to that, on all buildd hosts that are supposed to build packages for "oldstable" as well (not all buildds do), the old "stable" build chroot needs to be renamed to "oldstable" and "oldstable" needs to be enabled in the configuration.

Additionally, on all buildd hosts the "stable" build chroot needs to be updated to the current "stable," or the old "testing" chroot renamed. These are used by the security builds as well.

All this should be done synchronously, but wasn't. On July 7th I wrote in my logbook that the buildd network seems to be finally fixed. Actually it was fixed two days before that article. Before that, one part or another was missing or not fixed totally.

In the Project Leader Report, Robinson points out that there was a failure in infrastructure and communication:

I suspect, given what I know from conversation with some of the principals close to the infrastructure involved in getting our stable security updates out, that that's what we're dealing with. There have been technical failures and communication failures, with the former greatly exacerbated by the latter.

I have asked Andreas Barth to look into this situation and establish as clear a factual record as he can. Using this report, we should be able to attack the areas of weakness. One thing I'd like to see is better documentation of the internal workings of the security update process, perhaps in the Debian Developers' Reference. With a broader understanding of security workflow, I'm hopeful that people will be less likely to draw erroneous inferences about what the causes of problems are, and more likely to make offers of assistance that prove fruitful.

Robinson has also proposed making the security team DPL delegates, and points out that now would be a good time to add new members to the security team roster. Whether that has happened or not, however, remains up in the air. Schulze said that adding new members would be "discussed inside the security team." Robinson has not replied to e-mails asking about the security delays.

Schulze also said that the backlog of security updates that built up through June should be cleared out by now.

Around the same time, the Fedora Legacy project's security updates also seem to have been bottled up. The Fedora Legacy project has a gap for updates between June 5 and July 9, for all Red Hat and Fedora distributions supported by the Fedora Legacy project, Red Hat 7.3 and 9.0, and Fedora Core 1 and Fedora Core 2.

Some of the updates that were released in July by Fedora Legacy were rather tardy indeed. For example the GNU Mailman advisory (CAN-2005-0202), was fixed by other distributions back in February. The PHP advisory on July 10 from Fedora Legacy was addressed back in April by Gentoo, Mandriva and others. (Debian's fix for this bug came out in May.) This post on the Fedora Legacy mailing list from Jesse Keating acknowledges that the legacy project has longer lead times on security updates.

It would seem that Debian's infrastructure problems have been solved, at least for now. However, the gap in updates is somewhat alarming. As a rule, Debian has often been one of the first distributions to issue security updates and advisories, and has developed a well-deserved reputation for being quick to respond to security issues. We hope that the delay in updates while the project was transitioning from Woody to Sarge is a one-time issue, and that the transition from Sarge to Etch, whenever that happens, will happen more smoothly.

The importance of speedy security releases can't be emphasized enough. Aside from the obvious PR problems when a distribution is behind in updates, Linux users need to be able to depend on updates as soon as they can be made available so that they are not subject to exploits any longer than is absolutely necessary.

(Log in to post comments)