Debconf5: Securing the Testing Distribution [LWN.net]

This part of our Debconf5 coverage was inspired by a talk titled Securing the Testing Distribution given by Joey Hess. Debconf5 sign

Debian has several branches, including two currently supported stable branches, Woody and Sarge and the unstable branch, also known as sid. Though usually fairly stable, sid is in constant flux and provides a faster paced target for those who like run the latest and greatest software. The testing branch, on the other hand, provides a look at the next stable version still in development, in this case etch. Testing was first used when woody was in development. Once Woody was released as Debian 3.0 testing became synonymous with sarge. So now that Sarge has been released as Debian 3.1, testing has become etch which will someday to be the next stable version.

The supported stable version(s) (support for Woody will end before we will see an etch release) have a security team providing security updates. Often security fixes are backported to the stable packages. Packages in sid are usually upgraded to a new version of the package in which the problem has been fixed. Up to now there has been no mechanism to provide security updates for testing.

Some of the security issues in stable will have already been fixed in testing's newer packages, but for the most part security fixes have lagged behind stable and unstable. Packages fixed in unstable can automatically migrate to testing, if certain criteria are met, but that comes with a built-in delay. Unrelated release critical bugs in unstable packages could block the security updates from reaching testing. Ironically, those very users most interested in the shape of the next stable version are also those likely to be put off by the lack of security updates.

Those days have come to end. Now there is a security team for testing, with five to six team members and twice that on the mailing list. Some team members are Debian Developers (DDs), but that's not required. The team now proactively looks for holes, checking Debian testing packages against CVE entrys, bugs in the Bug Tracking System (BTS), and watching other security lists.

DDs and package maintainers were asked to document all security issues, including the CVE number in open bug reports. Change log entries and closed bugs should include a CVE number and indicate when security issues are fixed. Tracking and fixing security bugs in etch will make it far more appealing to potential testers, and may even help Debian achieve a more predictable release cycle.

Index entries for this article
Conference	DebConf/2005

to post comments

Debconf5: Securing the Testing Distribution

Posted Jul 21, 2005 12:25 UTC (Thu) by madscientist (subscriber, #16861) [Link] (1 responses)

It's good that someone is checking security issues in testing, but the article doesn't say (and I couldn't tell from the linked site) how security fixes would be applied to testing.

The major disadvantage to testing, as pointed out in the article, is that security fixes that appear in sid take a while to flow into testing (that's how testing is designed to work). So, is that being changed? What's the new model going to be?

Debconf5: Securing the Testing Distribution

Posted Jul 21, 2005 14:11 UTC (Thu) by syntaxis (guest, #18897) [Link]

"the article doesn't say (and I couldn't tell from the linked site) how security fixes would be applied to testing."

Joey Hess covered this in his Debconf talk: http://dc5video.debian.net/2005-07-12/08-Securing_the_Tes.... Obviously the best thing would be for you to download and watch it yourself, getting the information straight from the horse's mouth, but here's my attempt at a summary based on my impressions:

He reckons that using the testing-proposed-updates infrastructure would be the ideal solution (assuming it would have access to autobuilders, etc) but it's currently within the purview of the official *Stable* security team, of which he is not a member. Due to the Stable security team being a member of vendor-sec (i.e. having to keep fixes secret and embargoed until a mutually-agreed-upon date of public disclosure) they might have concerns about allowing outsiders the necessary access to security.debian.org, and perhaps they'd be worried about the additional load on their autobuild network possibly delaying updates to Stable. I guess they'd also have to work out exactly how the two teams would interoperate when Testing is next frozen (at which point the official Stable security team has historically begun to support it, uploading their own fixes to t-p-u).

In the short term, Joey proposes the Testing security team setting up its own repository (complete with its own autobuilders) focusing initially on x86 and perhaps a few of the other major architectures and expanding from there. It would be just another entry in people's sources.list.