On Wed, 26 Aug 2009 21:04:08 +0200, Moritz Muehlenhoff wrote: > On Wed, Aug 26, 2009 at 02:55:03PM -0400, Michael S. Gilbert wrote: > > 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). > > That's exactly why the unfixed/TODO items should _not_ be commited until > they've been verified manually. There's too much noise in embedded > code copies (like packages only embedding a small subset of code or > outdated entries).
understood, and that's why i am going to do this manual triage. we should probably force ourselves to be better at keeping embedded-code-copies up to date and accurate. mike _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
