[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

Thu Aug 25 20:41:27 CEST 2011

Op donderdag 25 augustus 2011 20:14:45 schreef Remco Rijnders:
+> On Thu, Aug 25, 2011 at 08:09:26AM -0400, Stew wrote in
+> 
+> <4E563B76.7080300 at gmail.com>:
+> >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
+