In the process of my work on the testing security team, I've noticed
that many developers still seem to be unfamiliar with how to use the new
version tracking features[1] of the Debian BTS.
Oddly, this seems to affect bugs about security holes more than regular
bugs. There seems to be some confusion about how to use the BTS to track
what versions of a package fixed a hole and which are still vulnerable,
and people rightly want to be extra careful about not forgetting to fix
security holes in stable. However, more often than not, they end up
shooting themselves in the foot instead by not using the BTS in the way
it is now designed to work.
Here are three simple rules that you can follow to make sure that the
BTS always has correct information about what version of your package
fixes a bug (especially a security hole).
1. When you fix a bug in a new version of the package, be sure to put
a correctly formed "Closes: #xxxxx" line in the changelog.
Do this even if you only fixed the bug for one distribution of
Debian and it still needs to be fixed for others. Keeping track of
what versions of a package still have the bug is what BTS version
tracking is all about. If you use the system as designed, it will
do the right thing. Trust me. If you don't trust me, trust Colin
and AJ.
If you find yourself sending an email to the BTS stating that "the
fix has been uploaded", you're doing something wrong.
2. If you forget a changelog entry, or find out about a fix (such
as a fix for a security hole) after your upload, send mail to
xxxxx-done@bugs.debian.org as before, but include a "Version:"
pseudo-header[2].
Again, this will allow the BTS, security teams, etc, to track what
versions of the package still have the bug.
3. Don't use release tags ("sarge", "sid", "woody", etc) to try to
indicate what distributions of Debian a bug effects. It doesn't
mean what it used to mean, and is now mostly useless.
Instead just close the bug with a "Version:" pseudo-header as
above, indicating what version of the package fixed the bug. The
BTS version tracking will do the rest.
There are some other nicities and tricks you can use with BTS version
tracking that are explained in Colin's mail[1], but if you follow the
three rules above you will be 95% of the way toward correctly using the
version tracking features, and you will save a lot of time for people
who use the BTS to check for things like security hole fixes.
I thought I'd conclude with an example of how to do it right, and wrong.
right: http://bugs.debuan.org/329839
wrong: http://bugs.debian.org/322133
--
see shy jo
[1] Which were announced and explained in detail here:
http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html
[2] For example:
To: xxxxx-done@bugs.debian.org
Subject: new upstream release fixed some security holes
Version: 2.0-1
CAN-2005-0000 was fixed in this upstream release.
Attachment:
signature.asc
Description: Digital signature