As promissed in http://lists.debian.org/debian-security/2003/debian-security-200304/msg00373.html I've written a rough plan...
Bugs get filed using appropriate procedure then... The "team to patch vulnerabilities" finds the bugs and starts its procedure... I still need to work on the procedure, and I'm thinking up a better name for the team. Perhaps "Debian Vulnerability Patch Team" or alike... I imagine most people on this team won't be Debian Developers or else they'd be on the Debian Security Team so some effort in naming is needed not to overlap or take away from their efforts... It occures to me that many may be interested in joining this "team" just for ego, resume fodder, 1337ness... To make sure this doesn't interfere with anything I won't be putting together a roster. If I do give credit it will based upon information available to me such as valuable contributions to the BTS, the Security Team, maintainer(s) and/or mailing lists. I don't keep any metrics on how much I've helped out and I regard this as time consuming and perhaps a waste of time. I don't expect to do it for others, but it'd be nice if someone did it for me. I also don't think it would hurt for people to keep track of their own contributions, and how helpful they were... if you want me to acknowledge it you'll have to give references to what you've done. I may also dispute various metrics... I don't want to see time wasted on flames though (hopefully not flames by me, I don't intend to flame, and I don't like flame-bate). ----- Some guidelines: New security bugs should follow proper procedure. Read http://www.debian.org/security/faq and note that whenever a new security bug is found send an e-mail to [EMAIL PROTECTED] If it's public knowledge or an extremely low risk and/or low hazard vulnerability then maybe file a bug in the BTS and set "Tags: security"... Some co-ordination between vendors and upstream(s) may be nessisary before vulnerabilities should be made public. Be careful not to file bugs that are not in Debian packages [1]. The BTS should be proprly used. Read through the documentation at http://www.debian.org/Bugs/ Please use the Tags as much as possible (security, potato, woody, sarge, sid, patch...). Please check if stable (now woody) oldstable (now potato), unstable (aka sid) and Testing (now sarge) could be affected. Don't assume that it is or isn't based upon its version number alone [2]. Give maintainers and the security team time to fix bugs. The security team's timeline *might* be directed by their policy(?) [3] to issue a DSA, fix or not, within one week. Maintainers *may* be given "a few days" to respond before people should bother writing a patch, and after a patch is submitted it is recomended to "wait a few more days" for a responce [4]. After the wait is up talk to a Developer about doing an NMU [5] or do one if you are a Debian Developer. [1] Debian "stable" sometimes has security patches backported from newer version numbers. Also there may be differences in the Debian version (that should only be in the Debian diff file) and upstream (which should be the same as the orig source). Security scanner false positives should be filed if and when they occure (Eg, nessusd). [2] In additon to [1], sometimes vulnerabilities are only introduced in later versions. Check the differences in the source code if you can (it'll need to be done eventualy), and try to exploit yourself if an exploit is possible/available. [3] http://lists.debian.org/debian-devel/1999/debian-devel-199908/msg01933.html [4] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu-when [5] Acording to http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00392.html debian-mentors@lists.debian.org might be the best place to request an NMU, but for example, an apache NMU request might go to debian-apache. Another good example is requesting an NMU of a package like libdb in debian-perl as a libdb RC bug affects perl. Note NMU's usualy don't get seen for at least 7 days after uploaded. Is there a way for non-dd (non Debian Developers) to check incomming/delayed? ----- Some Resources: http://qa.debian.org/bts-security.html lists bugs in the BTS that are tagged security. http://packages.qa.debian.org http://bugs.debian.org The Debian archive (it's a bit confusing to me still). It has source for all distributions that have the package (except maybe some non-free). Note that potato didn't use the pool directory structure. http://www.steve.org.uk/Debian/ is one example of a security audit that this team might help support 3rd party security information sources: http://www.securityfocus.org especialy under BIDs http://packetstormsecurity.nl and it's many mirrors CERT, other advisory places (like mitre or iss), vendors like Mandrake, SUSE, RedHat... For human help with patches: Upstream (see the copyright and files in the source, other bugs, a search engine...) Maintainers [EMAIL PROTECTED] (they're overworked so don't push them) debian-security@lists.debian.org and its archives at http://lists.debian.org/debian-security Debian mentors at debian-mentors@lists.debian.org and its archives at http://lists.debian.org/debian-mentors ----- Proposed procedure: First find a bug in the BTS (I'm trying to work on a way to priortize them better) then... Post information about your research frequently, but don't be annoying (eg, don't file minute by minute reports). Let people know what work you are doing to avoid duplication. Don't forget to cc people/lists/bugs when appropriate. 1- Verify that the bug exists (either by good code reading or testing). 2- Check for existing patches and workarounds or even complete new versions that fix the bug. 3- If upstream hasn't acknowledged the bug or been informed, let them know about the bug. Note: patches can be avoided if only unstable is affected and theres a new version that fixes the bug. 4- Check if exsisting patches fix the vulnerability (preferably by testing, but maybe by good code reading) 5- If a patch doesn't exsist, you *could* wait "a few days" (starting from the initial bug filing or first public release of relevant information). 6- If a patch doesn't exsist, and no relevent (eg maintainer) responce is given write a patch (Maybe with help from other sources or by other sources). 7- Don't forget to post patches to the BTS and set the Patch tag. 8- Check if other distributions are affected (sometimes maintainers accidentaly close security bugs that they fix in unstable when the bug is still in other distributions). Following steps 1, 2, 4, 6 and 7. Please set tags (potato, woody, sarge, sid) appropriatly if you notice only certain distributions are affected. 9- If it has been more than 10 days (since the initial public releace of relevant information), and the bug is in stable or oldstable, and it seems no fix to the security bug is pending ask the Security Team ( [EMAIL PROTECTED] ) for a responce (don't demand one, and don't demand a DSA). Note: I would consider old bugs (more than a month old?) to be acknowledged by the Security Team as they do occationaly read through the BTS. Please respect the tags pending, and fixed. It's ok to question wontfix and closure of security bugs, but be nice about it. If there's still objections, ask the security team and/or debian-devel@lists.debian.org for input. Note that sometimes a fix is pending but the information isn't in the BTS or isn't in there properly, please be nice about that. 10- If it has been more than 14 days and you feel an NMU is appropriate, make your case and ask for one in the appropriate forum (or to an individual). debian-mentors@lists.debian.org, [EMAIL PROTECTED] (developers private security list), debian-security@lists.debian.org and debian-devel@lists.debian.org are examples of generic forums that may be appropriate. Please follow the mailing list guidlines when sending messages to them. ... find anaother bug. Note: You don't have to do all the work. Please don't disregard the work of others. Please don't be demanding of others. Please be polite. Thank you. ;-) ----- I'm looking at a better way to priorize bugs. Perhaps similar to CVE's or BIDS do by saying remote, buffer overflow... but I'd also like to include visability and what's available/being used in the wild. I'd apreaciate some help with this as it's not clear right now to me what a good method is, and I'd rather be patching. ----- I'd also like to have regular updates taking about the status of security bugs in Debian... A team status report if you would. I guess I've volunteered to do this... I won't likely do much in the way of metrics saying how much help was given, what kind of help, what kinds of problems were created although that'd be nice. I really think it's important to have some metrics for known open security bugs though. I'd like it if someone else stepped forward and created such a status, again as I'd rather fix bugs. Drew Daniels PS: I've only mulled over this for an afternoon and have done no spell checking. I didn't bug [EMAIL PROTECTED] or the security team to comment on this either, which I hope is less bothersome than telling them implicetly and/or asking them directly for comment(s). I'm not a Debian Developer and am not speaking on the behalf of anyone but myself.
