>
> 1) as we are one file per release perhaps merging extras and core into one
> file. (not now but later)
This will depend on the outcome of the bizarre mating ritual that will no
doubt happen once core is freed.
> 2) use one file per CVE. has alot of files but you could have in it each
> effected release
This also complicates the issue of moving things forward. Right now, when
FE6 must be tracked, a 'cp fe5 fe6' is a pretty solid start.
> 3) Time based rotation of files. List in a similar manner to currently done
> but add the releases effected to the end and rotate files each
> month/quarter/half year/full year
I don't think this is wise. The files will be rotated when EOL is reached.
Having everything in one easy to find place for each distribution is easier
IMO.
We can also just keep tracking things the way they currently are, but I
fear it won't scale. One entry, per package, per distribution. This fails
to scale with something like mozilla.
For each CVE id a mozilla application is assigned, we have to add a CVE id
for mozilla, thunderbird, firefox, seamonkey, in the FC[45], FE[45], and
all the legacy files (for those of you not counting on your fingers that
would be 16 lines added). This isn't ideal, but the files are great for
tracking, simply because each one contains a good set of information. If I
want to know what products CVE-2006-0123 affects, all I have to do is
'grep CVE-2006-0123 *'
I think the answer is tools. The data the tools output can be whatever we
want, this particular format being something I like. You might like
something different, which would be doable as it's all just information.
Ideally I should be able to visit a web page, or create a YAML file (or
some other format/process you prefer) which will note which versions of a
product and which packages are or are not vulnerable, why, then file
bugzilla bits for us automagically.
--
JB
