On 11/1/09, Raphael Geissert wrote: > Steffen Joeris wrote: >> I am with Moritz here, if an issue is in serious need of fixing, it >> usually gets an RT ticket in one of the security queues (and quite often >> the first person that spots it and has the needed spare time fixes it). >> > > I think the process regarding RT tickets should be made a bit more public, > or at least documented. While this may work for stable and oldstable, it is > leaving unstable behind as an issue in unstable may not be addressed as > soon as in the stable releases. > > Cheers,
hi all, i was thinking about this problem some more recently and came up with the following conjecture: perhaps the key to making urgencies more useful is to define them as time-based; rather than qualification-based. for example, the definitions could be plain and simple: - high: an issue for which a fix optimally needs to be issued within the next 24 hours (with a 36 hour maximum). this category is primarily reserved for issues that are known to be currently exploited in the wild, weaknesses in cryptographic systems, and recently disclosed vendor-sec issues. - medium: an issue for which a fix optimally should be issued within the next 14 days (with a 1 month maximum) - low: an issue for which a fix optimally should be issued withn the next 6 months (with a 1 year maximum). obviously this categorization still remains very subjective, which is unavoidable for any system due to the sheer ammount of unkowns related to security issues. the key benefit is that these categories define very clear and useful objectives/goals for the security team to meet, rather than the current lack of any objectives, which would be very useful. note that the timeframes specified above are open for debate; those were just my initial thoughts. note that in this scheme, leaving an issue uncategorized would be undesirable because there may be high and medium priority issues among those that are undefined, so no one is aware that they should be prioritizing their work to get those issues fixed in the desired timeframes. it may also be useful to set up metrics in the tracker to see how well those objectives are being met down the road. as an aside, it may also be useful to do more claiming of issues so we know who is already working an issue. this would be especially useful if there are to be goals for getting the work done (so others know when to step in when something is falling through the cracks). i've been thinking about working on the new xpdf issues for a while, but i'm not sure if someone else is already on it or not. there is some documentation in the intro about claiming a section of issues in the CVE list, but i've never seen that used. maybe it would be more straightforward/useful if the claims were on a per-package basis, rather than full sections. for example, i could claim an issue by inserting my name into the parenthesis for the packages that i am working on, e.g.: - xpdf <unfixed> (low; gilbert-guest) mike _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
