Debian testing security team

Goals

The Debian testing security team is a group of debian developers and users who are working to improve the state of security in Debian's testing branch. Lack of security support for testing has long been one of the key problems to using testing, and we aim to eventually provide full security support for testing.

Activities

The team's first activity was to check all security holes since the release of Debian 3.0, to ensure that all the holes are fixed in sarge and to provide a baseline for future work.

Now the team is tracking new holes on an ongoing basis, making sure maintainers are informed of them and that there are bugs in the Debian BTS, writing patches and doing NMUs as necessary, and tracking the fixed packages and working with the Debian Release Managers to make sure fixes reach testing quickly. Thanks to this work we now have a web page, that tracks open security holes in testing and other branches of Debian.

The team is in the process of beginning full security support for testing by providing security advisories and fixes built against testing without the usual delays sometimes involved in getting a security fix into testing. These will be announced on the secure-testing-announce@lists.alioth.debian.org mailing list, and will be available in the following apt repository:

	 deb http://security.debian.org etch/updates main contrib non-free
	 deb-src http://security.debian.org etch/updates main contrib non-free
	

Data sources

Currently we're limiting ourselves to tracking security holes that have been the subject of a Debian Security Advisory, or are in the CVE database. It's very helpful to us if bug reports and Debian changelog entries include CVE numbers for security holes. If you don't have a CVE number, we can help you get one.

The team maintains a database (actually some files) that contain our notes about all CVEs and DSAs. This database is available from subversion, and may be checked out from svn://svn.debian.org/secure-testing/.

Uploads to the secure-testing repository

To upload a package to the secure-testing repository, any Debian developer may follow this checklist:

1. Only upload changes that have already been made in unstable and are blocked by reaching testing by some other issues. This is both to keep things in sync once the new version from unstable reaches testing, and to avoid breaking secure-testing too badly with fixes that have not been tested first in unstable.
2. Only make uploads for issues that the testing security team plans to issue a DTSA announcement for. Contact the team first to avoid duplicate work.
3. Use a version number that is less than the version number of the fix in unstable, but greater than the version number of the fix in testing. For example, if the fix is in a new upstream version 1.0-1 in unstable, upload version 1.0-0.1etch2 to secure-testing. If the fix is in version 1.5-10 in unstable, use version 1.5-9etch2 in secure-testing.
4. Use "testing" as the distribution in the changelog.
5. Build the package in a testing chroot using pbuilder so that all the dependencies are ok. Be sure to build with the -sa switch to include source, unless the source is already in the secure-testing archive.
6. Test the package.
7. Sign the package. Any Debian developer in the keyring can do so.
8. Upload to security-master.debian.org. Here is a dput.cf snippet for that upload queue:

   		[secured-testing]
   		fqdn = security-master.debian.org
   		method = ftp
   		incoming = /pub/OpenSecurityUploadQueue/
   		login = anonymous
   		

9. Once your fix is accepted, a mail will be sent to the secure-testing-changes list and, it will become available in this apt repository, including builds for all other architectures:

   		deb http://security.debian.org/ testing/updates main contrib non-free
   		deb-src http://security.debian.org/ testing/updates main contrib non-free
   		

   Build logs are mailed to the team, and must be signed. Once everything is ok, a team member will issue a DTSA.

To issue a DTSA, team members follow this checklist (note: this may change once newamber is fixed to use our templates):

1. Commit an initial .adv template into SVN to prevent duplicate work and claim an advisory number
2. Prepare the update and fill out the .adv template
3. Make sure everything is ready.
4. cd data/DTSA; ./dtsa -p ADVISORYNUMBER
5. check DTSA-n-1 and DTSA-n-1.html. Remove TODO line for advisory from the list file
6. mv DTSA-n-1.html ../../website/DTSA/
7. cd ../../website; ../bin/updatehtmllist --output list.html ../data/DTSA/list
8. cd ../; svn add website/DTSA/DTSA-n-1.html; svn commit
9. cd data/DTSA; ./sndadvisory DTSA-n-1
10. Edit CVE/list and DSA/list to list the version of the package that is in the secure-testing archive as fixing the holes. This is unfortunatly currently necessary for the fix to appear as a fix on the tracking page.

Note that the above instructions are provisional until we get everything set up.

Members and contacting the team

While some individual members may have sources of prior information about security advisories (such as vendor-sec), the team as a whole operates only on publically available information. Any Debian developers with an interest in participating are welcome to join the team, and we also welcome others who have the skills and desire to help us.

The team can be contacted through its mailing list, secure-testing-team@lists.alioth.debian.org. Please note that this is a public list, and as such, you should not send details of undisclosed vulnerabilities to this address. Our irc channel is #debian-security on the OFTC network. There is a second mailing list, secure-testing-commits@lists.alioth.debian.org that receives commit messages to our repository, new team members are encouraged to join it. The list secure-testing-changes@lists.alioth.debian.org receives automatic annoucements of fixed packages uploaded to our repository. An alioth project page is also available.

$Id$