[Secure-testing-team] Vulnerability impact on issues

[Michael Gilbert]

On Wed, 28 Oct 2009 14:58:28 -0600, Raphael Geissert wrote:
> Moritz Muehlenhoff wrote:
> > 
> > Or let's simply get rid of them at all.
> 
> Keeping it would allow us (and others) to see what and how should issues be
> prioritised.

i agree that prioritizing is useful.  it helps to decide which among
the present issues should be worked first.  it also makes it ok to
leave certain issues untouched for long periods of time (i.e. those with
low-urgency).  if issues were not categorized and left open for long
periods of time, it would look very bad, because without information to
the contrary, human tendency is to assume all things being equal, and
the conclusion drawn would be that many dangerous issues were being
left open.

i don't think redefining the meaning of low/medium/high to be based
solely on debian priority will make a whole lot of a difference; because
ultimately priority is dependent on the facts currently known about the
issue anyway. i.e. a flaw known to be used in existing exploits should
have a higher priority than one where that fact is not yet known. 

i think that the current system is ok, but we shouldn't be so worried
about getting the priority exactly right.  we also shouldn't be too
staunch about keeping the priority in line with the current definitions
just because of the written text in the introduction (all language
is subject to interpretation anyway).

i would however like to encourage initial gut-feeling ratings for all
incoming issues; primarily because it is unclear how you would decide
whether to work on a non-prioritized issue over one of medium
priority.  and as progress is made, if that gut-feeling rating was
wrong, then the triager should feel free to change the rating to
reflect the currently known state.

mike