Op donderdag 25 augustus 2011 20:14:45 schreef Remco Rijnders: > On Thu, Aug 25, 2011 at 08:09:26AM -0400, Stew wrote in > > <[email protected]>: > >On 08/24/2011 08:50 PM, Samuel Verschelde wrote: > >>Hi, > >> > >>I was told that QA Team's work's visibility needs to be improved, so as a > >>team member I'll try to give you some sort of status report. > >> > >>- 1 has been validated by QA one month ago, but was assigned to security > >>team following updates policy for security fixes, and got not answer. We > >>have to improve either the policy or the security team here (or both). > > > >Do you have a pointer to this bug? I'm not finding it in bugzilla. > >I'm not sure what I can do with it once assigned back to secteam, > >aside from write an advisory text. I don't have admin rights to > >release it, etc. (afaik). It was basically my understanding that the > >secteam role is to initiate the bug, provide patches, POC, and > >advisory text and the maintainer do the update and pass it on to QA. > >I've stopped even intiating because they are just sitting there in > >the new/unassigned state. some for 2 months or more now. While a > >shiny new KDE is nice, not pushing updates for published > >vulnerabilities makes us look bad, imho. > > I think what we need is a trinity of triage, secteam, and QA to work on > security related things. Triage team will assign or cc the security team > on security related bugs as efficiently as possible, from there security > team will work with the maintainer on the fix and hands it to qa for > (expedited) testing and release. > > My personal feeling is that security is too important a thing to leave up > to an individual maintainer or last committer to fix, especially when it > is remotely exploitable. Perhaps make a distinction on the severity of the > security issue? > > - If it needs an authenticated user for an exploit to work, assign it to > the maintainer, Cc security team. If there is no response from the > maintainer after x days (say 10 or so), security team takes over > responsibility. > > - If it is remotely exploitable and leads to a DoS or take over, security > team is instantly responsible and Cc's the maintainer on the bug and > works on a quick update. > > In my opinion it is more important to be concerned with the safety of our > users machines than with perhaps stepping on a sour maintainers toes. > > Perhaps in the next packagers meeting something like this can be agreed > on? The security team needs to have the needed privileges to quickly > handle security issues the best way it sees fit. > > Remmy
+1
