[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the Security Team

Hash: SHA1

Bits from the Security Team

It's in the nature of security support that in the ideal case users
shouldn't notice our work at all. Still, there're some noteworthy
changes you should know about.

Debian Security Tracker

The Debian Security Tracker is a database which collects information
about security problems and provides an easy overview about open
security problems in a given distribution:


Various sources of information are tracked there:
- - Information from Debian Security Advisories and the versions which
  have been fixed
- - All CVE ID assignments from MITRE are validated, whether they affect
- - References to security bugs reported in the BTS
- - Information about updated security fixes provided for testing

The Security Tracker covers Debian's security history back to 2003. It
is discussed on the mailing list debian-security-tracker@lists.debian.org
You should subscribe if you want to get involved.

A more verbose introduction into the Security Tracker and how to get
involved can be found in:

Embedded code copies

Developers are encouraged to communicate amongst their colleague
developers for cases where their packages have code in common with
other packages. For example a package which contains an embedded
library which is also packaged should be encouraged to use the shared
library, as this means a potential security update only requires a
single update.

A prominently horrible example is the xpdf code base which is embedded
in ten different source packages in Debian Sarge. (For Debian Etch
this could already be reduced significantly thanks to the xpdf library
fork named poppler and for Lenny we'll reduce it even more)

You need to tell us about such cases, we can't review all of Debian's
18k packages on our own.

The current state of affairs can be found at:

Architecture versatility

We endeavour to release security advisories for a package for all
architectures simultaneously.  Sometimes that isn't possible because
the network we use for rebuilding packages contains machines which are
broken, or otherwise unavailable.

A recent example of a problem architecture would be the HPPA port of
Debian, which had no working build host for some time, and caused all
pending security advisories to stall. In some cases we choose to
release without the architectures in question.

Separate queue for unembargoed security problems

A subset of all security updates is embargoed, i.e. Debian receives
pre-notification about a security problem along with an embargo date,
until which the fix is to be kept private. Traditionally all Debian
security updates have been built in a build queue hidden to the
public. Thanks to infrastructure improvements implemented by Anthony
Towns security updates without an embargo can now be built in a second,
visible queue.

A provisional overview of this queue can be found at

There are still some bugs that need to be fixed until this will be
used for all security updates, though.

Security mirrors

In addition to the mirror rotation available for security.debian.org,
security mirrors can now be accessed regionally:

security.eu.debian.org resolves to villa.debian.org and lobos.debian.org
security.us.debian.org resolves to steffani.debian.org

The IPv6-enabled security mirrors are reachable as security.ipv6.debian.org

Request Tracker

The Debian Security Team is planning to use the Request Tracker now
available at rt.debian.org. We will post a status update once more
details have been settled and the queues have been created by the
Debian System Admiministrators.

Debtags for the scope of security support

Sometimes it is necessary to revoke security support for a given
package. During this year's DebConf conference it was discussed to use
debtags to flag such a state. The following bureport contains more
information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436161

If you have further suggestions, please add it to the bug log.

New members

Florian Weimer and Thijs Kinkhorst have joined the Security Team

Long term maintainability

One of the many benefits of Debian over other GNU/Linux distributions
is the versatility of our archive. In contrast to most other
distributions Debian provides long term security support for the full
selection of packages available in the archive and not only a subset
expected to be the most commonly used. 

Security support is provided for the lifetime of a release plus one
more year, i.e. at least 2.5 years according to current release
schedules. (Debian Woody was supported for nearly four years)

If you have doubts about the maintainability of your package for such
a time frame you should contact team@security.debian.org. If we know
in advance we'll deal with it, if you don't tell us, it's your fault. :-)

How you can help

* As a package maintainer: If there's a security bug in your package,
  please be proactive about it (do not wait until the security team
  releases a DSA all by itself). You can help prepare updated
  packages for stable and oldstable following the guidelines on

* Always mention any applicable CVE id's in your changelog. If an id
  is assigned after you uploaded the fixed version, please add it
  retroactively in a next upload.

* A good way to help is to research more information, reproducers and
  of course patches for bugs tagged "security" in the BTS.

* Helping out on the information in the Security Tracker (see above) is
  a good way to help both the testing and stable security teams in one go.

* Users may help us by reporting problems which are not already
  contained within the tracker mentioned above, by adding the
  'security' tag to existing bug reports and, if necessary,
  removing a misplaced "security" tag.

Where to find more information

If you're curious about the security team and would like further
information about anything contained in this message the following
links would make a good starting point:

    * The Debian Security FAQ

    * The Debian Security website

If you have more specific questions please ask us directly by mail.

If you wish to establish encrypted communication, you should use the
current team PGP key 0xF2E861A3.
Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: