On Mon, 2005-10-24 at 19:39 +0200, Florian Weimer wrote: > * dann frazier: > > > Horms: I realize you might be somewhat out of the loop as to how we're > > abusing your directory tree; I'll catch you on IRC when you're back to > > explain in detail. > > Could you write a short statement to the mailing lists, please?
Sure - good idea. Micah and I have created an evolving schema, using rfc822-style files. Currently we're storing this data in svn://svn.debian.org/svn/kernel/people/horms/patch_notes, though we should probably move it elsewhere once we've settled on the architecture. I proposed the rfc822 layout because its familiar to Debian people, and I have a small python library that I can use to read & write this format. The idea is we'd have one rfc822 file per patch, and include all relevant information there - including CVE status, inclusion status across currently maintained source trees, description information, etc. If you look in Horms' cve directory today you'll see a lot of CAN-XXXX-XXXX files - we're thinking about making this ID just a field in the file named after the patch, so those may go away - ignore them for now. Currently, our file layout looks like this (slightly modified for example's sake): $ cat net-ipv6-udp_v6_get_port-loop.patch ====================================================== Candidate: CVE-2005-2973 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2973 Reference: CONFIRM:http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED] Description: Fix infinite loop in udp_v6_get_port(). Bug: fixed-upstream: 2.6.14-rc4, 2.6.13.3 2.6.13: released (2.6.13+2.6.14-rc4-0experimental.1) 2.6.8-sarge-security: pending (2.6.8-16sarge2) 2.4.27-sarge-security: pending (2.4.27-10sarge2) >From here you can gather that this is a security fix that went into 2.6.14-rc4. Its been released in our 2.6.13 source tree, starting in version 2.6.13+2.6.14-rc4-0experimental.1. > For example, I'd like to get a list of the 2.6.12.6 security bugs > which have *not* been assigned CVE names. Which data sources shall I > combine to obtain this information? Eventually, and this is very subject to change - especially as we haven't discussed this with Horms yet, you should be able to follow this process: Look in all files for a fixed-upstream field containing 2.6.12.6. In those that match, look for a Candidate field with the string "##NEEDED##". I think the biggest problem your example will have with this data format is that we aren't tracking patches by the upstream release they arrived in. You'll have to count on either having your own list of patches that came with 2.6.12.6 and mapping those to our patch names, or count on someone being diligent enough to keep the fixed-upstream field up to date. -- dann frazier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
