Comments and proposals for security bugs
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
Reply to: