On Mon, 11 Jan 2010 19:28:48 +0100, Moritz Muehlenhoff wrote: > 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.
As I said before, I have compromised on my viewpoint so that this will not be the case. > <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). <undetermined> is not meant for "dubious" issues. It is meant for any issue that needs further investigation before declaring fixed/unfixed. See documentation [0]. > I don't have time for a lengthy discussion about this. Discussion is healthy (although I think we've pretty much reached a conclusion/consensus at this point). > 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. Any workflow changes will happen due to free will adoption of the new features. I do not intend to force anyone to do anything. > > 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. Agreed. Like I said, that's the plan (but the note will use kinder language). Mike [0] http://lists.debian.org/debian-security-tracker/2010/01/msg00014.html -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
