Secure testing team - Mar 2006 - Recording fixed versions in sarge

Florian Weimer wrote:
> If you don''t object, I''d like to add version information
for sarge to
> the data/CAN/list file.  The reason is, of course, that it doesn''t
> make sense to maintain the CVE mapping in two different places.
I''d recommend to wait two more weeks. The infrastructure (especially
wrt tracking stable) might change after the Oldenburg meeting and I
think it would make more sense to discuss this a piece of something
larger.
 
> PS: There are quite a few typos in the packages in the data/CAN/list
> file. 
Thanks for these, there were some really embarassing typos rotting...
> Maybe it would be a good idea to include package lists in the
> repository (without version information because it changes too
> rapidly), so that consistency checks could be performed locally?
This would only be useful for checking new entries, as the package
list is in flux and I''d rather not want to rewrite history. (e.g.
we have several bugs against openwebmail, which is no longer in
the archive). A script like this would be very useful, indeed.

Cheers,
        Moritz

* Moritz Muehlenhoff:
> Florian Weimer wrote:
>> If you don''t object, I''d like to add version
information for sarge to
>> the data/CAN/list file.  The reason is, of course, that it
doesn''t
>> make sense to maintain the CVE mapping in two different places.
>
> I''d recommend to wait two more weeks. The infrastructure
(especially
> wrt tracking stable) might change after the Oldenburg meeting and I
> think it would make more sense to discuss this a piece of something
> larger.
*shrug* I can keep the changes private.

The data has to be collected and consistency-checked anyway.  I
somehow doubt that the stable security team keeps an up-to-date
super-secret bug tracker.
> This would only be useful for checking new entries, as the package
> list is in flux and I''d rather not want to rewrite history. (e.g.
> we have several bugs against openwebmail, which is no longer in
> the archive). A script like this would be very useful, indeed.
We could keep a list of ex-packages.  I think I''ll have to create a
sarge-ignore list anyway.

If you don''t object, I''d like to add version information for
sarge to
the data/CAN/list file.  The reason is, of course, that it doesn''t
make sense to maintain the CVE mapping in two different places.

The format I want to use is:

  - hello 2.1.1-5 (bug #nnn; low)
  - hello 2.1.1-4sarge1 (sarge; bug #nnn; low)

The "sarge" flag indicates that this line applies to sarge only.

This format has the disadvantage that some of the data has to be
duplicated.  However, I might even need the added flexiblity because
bug archival might force me to file a new bug for sarge, and the
urgency could differ for various reasons.

If this format (and the whole plan) is acceptable, which script files
should I change accordingly?  Is checklist the only one?

PS: There are quite a few typos in the packages in the data/CAN/list
file.  Maybe it would be a good idea to include package lists in the
repository (without version information because it changes too
rapidly), so that consistency checks could be performed locally?  (I
will commit the fixes once my group membership information on costa
has been updated.)