On Fri, 8 Jan 2010 11:59:52 pm Michael Gilbert wrote: > On Fri, 8 Jan 2010 17:40:48 +0100, Moritz Muehlenhoff wrote: > > Michael Gilbert wrote: > > > In order to address some usability, clutter, and transparancy issues > > > with the tracker, I propose to make the following changes: > > > > > > 1. By default, the per-release pages (e.g. [0]) will only show low, > > > medium, and high urgencies. > > > > Plus issues where no severity is set. > > See below. > > > By default issues which are set <no-dsa> should not be displayed as well, > > since they're triaged security-wise. > > Agreed. > > > > 2. All blank urgencies will be converted to "undetermined". > > > > No way. <undetermined> should be used for fishy issues where no > > sufficient research has been done (like for the ltdl or expat mass bug > > filing, where 50% of the initial reports turn out to be false positives). > > Agreed. I had spent some time contemplating the implications (shortly > after I hit send), and I concluded the same thing. <undetermined> is > definitely not right for these cases. > > > 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). FYI, the security team has 3 queues on rt.debian.org, one public queue and two private queues (one is the incoming queue for new tickets and one is just for embargoed issues). Tickets are created manually on RT and a member of the team takes ownership of the ticket to indicate that he's working on a DSA (and to avoid duplicated efforts). People that don't have an RT login can use the guest account to login and see the public security view to get a feeling for it. As said, tickets are created manually so they might not correspond to the urgency set in the tracker (although critical issues get fixed pretty quickly). Cheers Steffen
Attachment:
signature.asc
Description: This is a digitally signed message part.