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 _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
