Re: Proposed refactoring of the per-release tracker pages
On Mon, Jan 11, 2010 at 11:59:32AM -0500, Michael Gilbert wrote:
> On Sun, 10 Jan 2010 14:52:11 +0100, Moritz Muehlenhoff wrote:
> > Michael Gilbert wrote:
> >
> > > > As said before the severity is irrelevant, hardly to classify and only
> > > > used for some priorisation. They should not be mandatory.
> > >
> > > I personally think that urgency does have relevance, which I've
> > > mentioned a few times before [0],[1],[2]. In particular, it is very
> > > useful for those with an outside perspective (i.e. users that depend
> > > on their OS to be trustworthy, but lack the skill to understand the
> > > impact of security issues; and even for those users that are skillful
> > > but don't have free time to spend studying each individual issue).
> > > In summary, the advantages are:
> > >
> > > 1. A lot of open low-urgency issues in your operating seems like a much
> > > better situation than a lot of open undefined severity issues. This is
> > > especially important for the numerous users who don't have the
> > > patience/skill to understand the impact themselves.
> > >
> > > 2. From an uncertainty perspective, if you have a system with three
> > > states, but you don't have any information about which of those three
> > > states the system is in, you have to assume the worst-case scenario.
> > >
> > > 3. From an internal (to the debian security team) perspective, it helps
> > > to prioritize work, which is a good thing (although I read somewhere
> > > that there is an RT system behind the scenes, so I don't know if that
> > > supercedes urgency).
> > >
> > > Now, I understand that making urgencies mandatory has been deemed
> > > undesirable from the team members, so that is not a good solution. But
> > > on the other hand, I think they urgencies are very useful and
> > > important. So we have two conflicting percpectives, but I think a
> > > compromise can be made.
> > >
> > > I propose to show all unspecified urgencies as low in the tracker.
> >
> > That's only adding confusion. It often happens that we know that
> > there is an issue (e.g. because an upstream mentioned it in the changelog),
> > but noone had the time to look into it. It that case it should be tracked
> > with unspecificed urgency, just as it's currently done.
>
> This is the exact case where <undetermined> is meant to be used. Like I
> mentioned before, <undetermined> is intended to supersede any other way
> of tracking partially triaged issues.
Urgencies should not be mandatory, I don't add them currently in most cases
and I don't intend to do so in the future. Support for <undetermined> can
only be added if it doesn't change the current workflow.
<undetermined> can be useful if we have a large scale amount of dubious issues
which need further investigation, but not for the standard case, where we know
pretty exactly that a vulnerability exists (usually because it's mentioned
in an upstream changelog).
I don't have time for a lengthy discussion about this. To summarise:
Don't change the current workflow. You're free to add a new issue status, but
don't cause regressions in the current way things operate.
> Once again, I have again been rethinking this idea, and I am willing to
> compromise further:
>
> I propose to use the nvd urgency for all unspecified urgencies (and for
> clarity there will be a double-star note in the tracker to describe
> where that info was derived from).
>
> Logic: the work to categorize the impart/urgency has already been done
> (by supposed experts) elsewhere, so lets make use of it. Of course the
> nvd analysis may be wrong, or it may not adhere to debian guidelines,
> but of course it will remain possible to override the data for those
> cases.
As long as there's a disclaimer that NVD is automatically computed and
often completely senseless I'm fine with it.
Cheers,
Moritz
Reply to: