This part of our Debconf5 coverage was inspired by a talk titled
Securing the Testing Distribution
given by Joey Hess.
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
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
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.
to post comments)