[Secure-testing-team] inject-embedded-code-copies
Michael S. Gilbert
michael.s.gilbert at gmail.com
Wed Aug 26 18:25:19 UTC 2009
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.
> Just send it to a different file and add it to the PTS, this gives
> much more awareness for the maintainers. We already have enough TODOs
> of actual security issues which need attention.
an unaddressed embed is a security issue.
mike
More information about the Secure-testing-team
mailing list