News from the Debian security team [LWN.net]

By Jake Edge
March 12, 2008

A note from the Debian security team shows a number of new initiatives and plans. The team recently expanded by two while looking for up to two more folks to round it out. That, coupled with a number of new initiatives makes for some interesting news from the Debian security world.

Adding people to the team adds more eyes to find bugs, but, perhaps more importantly, adds more hands to actually patch the code when bugs are found. In many cases, the upstream project will fix the vulnerability in its latest release, leaving the distribution security team to backport the fix into whatever version they are shipping. This takes knowledge; one must understand the code and how to build it for Debian. They have not set the bar low for the kind of folks they are looking for:

You need to be familiar with how the wide variety Debian packages are maintained, patched and built. If you're not scared by packages generating their patch series by applying sed statements from cdbs include files before passing the patches through an awk filter to quilt until they're finally built with yada, you might be the right person.

The team is now using Request Tracker to track security bugs and updates. Two separate categories have been established, one for upstream bugs that are not yet public, the other for publicly known bugs. This allows the team to track all the bugs, but not prematurely release information about security vulnerabilities that are not yet public.

Two other changes will help with the quality of security patches. The first is a public patch review mailing list that is being formed to allow interested parties to see what patches are being proposed. Presumably this would only apply to public vulnerabilities or the list membership will need to be tightly controlled.

The other quality boosting change is to use the time between when a patch is completed and when it is has been ported and built for all of the architectures to further test the patch. The team is looking for large installations that normally install security updates in their own test environment before rolling them out to their live systems. Leveraging those test environments to further exercise the patched code can only lead to better code in the long run.

Security is an important part of any distribution, so it is nice to see these kinds of initiatives. More team members, testing, and tracking are all likely to bring about a faster and better response to security problems in the future.

(Log in to post comments)