[Secure-testing-team] [Secure-testing-commits] r13611 - data/CVE

[Michael Gilbert]

On Sun, 20 Dec 2009 10:09:00 +0000 Moritz Muehlenhoff wrote:

> Author: jmm-guest
> Date: 2009-12-20 10:09:00 +0000 (Sun, 20 Dec 2009)
> New Revision: 13611
> 
> Modified:
>    data/CVE/list
> Log:
> revert previous commit: CVE/list is not a dumping ground for issues
> someone should check based on embedded-code-copies.

the information inserted in this commit was derived from
embedded-code-copies, so it is accurate.

> If something is added to CVE/list as unfixed it needs to be checked
> beforehand.

as stated in the bug reports, i have asked the maintainers to check
these problems themselves.  once they get back to me, i will update the
tracking based on their feedback.  i understand that this is certainly
not ideal, but there are no other viable options given the fact that
there an incredibly high number of untriaged embeds right now. if i am
ever going to get through this embedded code copies triage, i need a
way to record partial progress.  otherwise, it will be impossible (at
least for one person).

so, i had to decide between either this or TODOs (or not doing anything
at all), and you had mentioned previously that you don't want any more
noise in the TODO list.  so, here are the tradeoffs:

TODO:
- disadvantage: clutters TODO page
- advantage: does not indicate issues are <unfixed> when they are in an
uncertain state
- disadvantage: increases likeliness of issues getting forgotten since
TODO page is overloaded

<unfixed>:
- advantage: doesn't clutter TODO page
- disadvantage: it isn't really known that the problem is <unfixed>,
but that fact is included in the bug report
- advantage: shows up in package page so developer is more aware that
they have something they need to work on
- advantage: shows up in debsecan indicating something needs to be done
- as a general aside, it has seemed to be ok recently to use <unfixed>
for untriaged or partially triaged issues, so why can't this also be
done for the packages potentially affected by embedded code?

don't do either:
- advantage: absolutely no clutter
- disadvantage: legitimate important security problems go unaddressed
since they are not being tracked.

i've also just thought of a fourth option; an additional file called
in-progress (or an <in-progress> status in data/CVE/list):
- advantage: no clutter in TODO list and no issues marked as <unfixed>
when that hasn't been determined yet
- disadvantage: information is separate from main files, and will
include primarily duplicated information anyway
- disadvantage: differs from normal way of working
- disadvantage: info stored there won't show up anywhere else (in
tracker or package pages), so it will not show up in front of as many
eyes

thank you for any additional guidance based on this feedback.

best wishes,
mike