There are many questions and comments about how the security team, RM and others handle security bugs. Some change is desired by at least several people. I've already started trying to help clean up security bugs. I won't even bother volunteering for the security team until I've had my identity verified (...no key and ~6h to a Dd... it'll happen though).
I'd propose that: Package maintainers: - should be in charge of fixing RC bugs in their packages in Testing and Unstable. NMU's should of course be allowed in the usual fashion, with RC bugs being allowed to get NMU'd faster. - track their RC bugs in stable, testing and unstable publicly and not forget about oldstable while it's supported. The RM and those with authority (mini RM's?): - allow and encourage RC bugs patched packages to go into testing-proposed-updates (in the same way it's done with stable) - decide if they want to bother moving packages from testing-proposed-updates to testing (this could be problematic in tracking bugs or upgrading from packages in testing to later ones in unstable). The security team: - Adopt a policy such as the one discussed [2], but preferably a modified version to reflect current practices - Include any available information about testing in their DSA's (the same as they currently do for unstable) - Pass any information about potential security bugs to maintainers, and when they're public, file a bug in the BTS (they already do this for the most part) - Not have to check if testing packages are vulnerable - Not have to release DSA's for packages not vulnerable in stable and oldstable - Not allow packages Some volunteers could help: - Colin Watson write the version tracking BTS - track security bugs [4] that are in advisories, alerts, reports... and put public information into the BTS (see [3] for details) - make sure bugs (particularly security and RC bugs) are tagged properly (including checking what distributions are affected) - verify information that's in the BTS (especially see http://qa.debian.org/bts-security.html ), maybe using the confirmed tag I haven't looked at it's use yet. - write patches for RC bugs in stable, oldstable, testing and sometimes even unstable, put them in the BTS and tag them +patch - do or at least prepare NMU's for packages when appropriate (see [3] for some details) - maintain a conflicts based solution to RC bugs (if there's a bug in only one program in a package, how should that be handled? Especially a minor program in a package with many reverse dependencies) I am personally of the belief that security updates for testing should go to testing-proposed-updates or alike and not security.debian.org Archives in security.debian.org would then have to track later versions of packages in testing so as not to be out of date. I feel that this could only be reasonable/acceptable after a nearly solid freeze. Security in testing and unstable almost requires BTS version tracking or at least version tracking of RC bugs. mdz told me, and debian-devel recently, that he's tracking what versions close security bugs. In a private email he also told me that he's working on an interface and that he can't release the information publicly right now as it sometimes contains private information (probably for things like CERT co-ordination of advisories). If you check the archives of debian-mentors and then debian-debugs you'll see that Colin Watson is planning to work on version tracking for the BTS (don't bug him, but if you're interested in contributing, talk in debian-debbugs). A conflicts based package solution could work a great deal nicer with a version tracking BTS. A conflicts based solution might not have to care about the minor program in a major package issue, nor have to track to see when a testing fix makes it into testing, but it certainly would be helpful. It'd also be nice if a conflicts based solution could have version conflicts to allow fixes from unstable, stable or oldstable. I can say for certain that there are outstanding DSA worthy issues (e.g. ptrace in the Linux Kernel, see [1] for details), but I can't say as to when or if they will be released. I've been hoping that a security policy could be adopted such as earlier ones discussed in an old debian-devel thread [2]. It was suggested (implied by two statements in [2]) that advisories should be issued within one week even if a patch is not available, while I don't totally agree with that, I would like there to be a canonical place to track *public* security bugs. A public security bug is one that has been reported elsewhere (see [3] for some places). There is a problem with this in that it takes a great deal of time and effort to verify that the bug actually exists in even the two versions of packages that the Security team supports. Temporary advisories seem to happen infrequently if at all (see the open security bugs), and imho for good reasons like the exploit has low hazard/low risk/mitigating factors. I'd still like to see a method to track the status of public security bugs. Perhaps the interface that mdz is working on could be used to track the work status and priority of security bugs if it is able to and publicly available. This method would also be better for tracking RC bugs in testing and unstable. I've discussed how to help with security bugs [3] on debian-security. I'd add though that the security team doesn't want to hear about bugs that haven't been confirmed to be in oldstable or stable. Some maintainers don't handle security bugs optimally (don't tell the security team, fix a bug in unstable but no where else...). One person who I talked to who's found several security bugs in Debian said he had a great deal of trouble getting the bugs even acknowledged. As Steve Kemp has already said, http://qa.debian.org/bts-security.html lists many open security bugs. I'm in the process of verifying them, writing patches and contributing my knowledge to them. I'm also making a status list for them. I'm looking at taking the popularity contest, bug status information and generating a priority list. In [3] I discuss the many things that can be done for security bugs. As to when bugs get closed, maybe there's no problem, but I think the developer's reference saying "Once a corrected package is available in the unstable distribution, you can close the bug" (5.8.3, #6) is not the best way. Perhaps another place to track public security (and other RC) bugs is desirable (mdz is working on a private system which perhaps he'll make partially public), perhaps the convention in the developer's reference should be changed, or perhaps we should wait for a version tracking BTS. I've read in several places, some Debian Developers feel that bugs should not be closed until they are fixed in all Debian distributions. This is likely due to the potato and woody tags. I tend to agree with this. I can site examples where security bugs in unstable have been closed, yet still exist in other Debian distributions (eg 94869 which I refilled). Colin Watson agrees with me [5] and is going to be extending the BTS. A document about the BTS extension can be found at: http://bugs.debian.org/~cjwatson/version-tracking.html There was some talk about having more "testing" distributions. Erich has some interesting ideas [6] about this. More testing distributions make updates more complicated, make more work for maintainers and infrastructure facilitators, and takes more resources. Personally, I run/ran unstable only updating specific packages when I saw the need (by looking at the changelogs) and this avoided many problems. It'd be nice to see a better way to do this (maybe it can now with the way the PTS handles changes files or "news"), but that's a different issue... xdiffs is another issue too :-) All this is on my new todo list. [1] http://lists.debian.org/debian-security/2003/debian-security-200305/msg00129.html "As soon as an incident is known the Security Team work on fixing affected packages." and: "If the exploit/fix is known and Debian is able to fix it within one week..." ...If it takes longer to fix such a bug, the Security Team releases a temporary advisory, warning the users and asking to disable the service or whatever is needed. This shall be released by a later advisory when the bug is fixed. [2] http://lists.debian.org/debian-devel/1999/debian-devel-199908/msg01933.html [3] http://lists.debian.org/debian-security/2003/debian-security-200304/msg00381.html [4] I've been "asked" by Joey not to bother the security team with security bugs that I can't verify are in stable or oldstable... I also of course don't get a nice reception by maintainers when passing on bug information that I haven't checked. Perhaps this will change with the "confirmed" tag. For now I'm trying to track public security bugs using debian-security. [5] RC Bugs should be closed only after they are fixed in all effected debian distributions. http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00047.html [6] http://people.debian.org/~erich/woody+1/ under "experimental is what unstable was supposed to be" Footnotes are numbered out of order but they correspond. Writing this message took too long as is and may have incomplete explanations, but I hope they're good enough or could be acceptably explained later. I hobbled this together from all my different comments on related matters. I just hope there aren't any scorching flames. Drew Daniels
