On Wed, 2011-05-18 at 16:28 +0000, "Jóhann B. Guðmundsson" wrote:
On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with <insert type of exploits here )?
I kinda considered that to be implicit in the criterion as written, but as two people have asked about it, obviously we should clarify that :)
Don't we need individual(s) from the security team that will be doing actively security audit during the development cycle and reporting back to QA?
Well, 'enforcing' the criteria is a separate issue from determining them, and we don't really need to discuss it here. Having an explicit criterion adds value even if we don't set up a formal validation system, because it gives us solid ground to review any security issues which get proposed as release blockers on an ad hoc basis.
Would not applying this security release proposal to final only suffice?
Well, I mean, it depends what you mean by 'suffice' :). I worked on the basis that we probably don't want to ship any widely-distributed 'release' with a major security issue, but as I wrote, it's certainly up for debate.