[Secure-testing-team] inject-embedded-code-copies

[Michael S. Gilbert]

On Wed, 26 Aug 2009 20:24:36 +0200, Moritz Muehlenhoff wrote:
> On Wed, Aug 26, 2009 at 02:25:19PM -0400, Michael S. Gilbert wrote:
> > On Wed, 26 Aug 2009 20:01:42 +0200, Moritz Muehlenhoff wrote:
> > > On Wed, Aug 26, 2009 at 01:59:58PM -0400, Michael S. Gilbert wrote:
> > > > On Wed, 26 Aug 2009 19:29:10 +0200, Moritz Muehlenhoff wrote:
> > > > > You should redirect the TODOs in a file separate from CVE/list, 
> > > > 
> > > > thanks for looking at this.  i personally think that the cve list is
> > > > the best destination.  the reasoning is that cve TODOs are good
> > > > indicators of what needs worked on and they are associated to specific
> > > > cves.  also, the TODOs show up on the security tracker website and are
> > > > used by various scripts.
> > > > 
> > > > yes, the first update from this script will commit over 400 changes,
> > > > but assuming those issues are addressed or marked <not-affected>,
> > > > subsequent updates will be much smaller.  the important thing is that
> > > > running this script increases awareness that a package that you're
> > > > dealing with is embedded elsewhere, and for that to be effective, it
> > > > needs to update the cve list.
> > > > 
> > > > > otherwise it clutters the list too much.
> > > > 
> > > > if you believe that the current formatting is too cluttered, i am
> > > > certainly open to suggestions. off the top of my head, for each
> > > > affected cve, i could compact the current one line per embed into one
> > > > line total for all embeds in that cve.
> > > 
> > > Working through the list is mostly a QA issue.
> > 
> > if you want, i can go through the generated list, triage most of the
> > TODOs, and mark them either not-affected, fixed, or unfixed before
> > uploading any changes; then only a few TODOs (for perhaps complicated
> > issues) will remain.  it may require a significant amount of my time to
> > get this done, but i'll do what it takes.
> 
> Great, all confirmed issues can then be added as TODOs to CVE/list.

btw, my script is already smart enough to exclude fixed embeds; it uses
the <unfixed>/<removed>/<unknown>/<itp> tags in embedded-code-copies to
determine if an issue is open or not.  so as long as the data in
embedded-code-copies is accurate, then my script already only generates
TODOs for real issues.  hence, when i am done with this triage, you can
expect a lot of new <unfixed> entries (probably close to 200).

mike