On Wed, Aug 16, 2006 at 05:07:31AM +0200, Goswin von Brederlow wrote: > Could we quantify that somewhat? Is one security bug enough? Are 10? > Do we have a delegate that could audit and veto a package already > other than the release team? Is that the domain of QA or security? > > Maybe any new package (one not in stable already) that has a security > bug could be automatically blocked from the next stable release until > a source audit by some team (security? qa?) is done? Doing this for > every new package is probably too much to ask timewise but for any > package known to have one exploit already that seems prudent.
imo, that is a separate, more proactive problem to solve - and for that, metrics will probably need to be created, used, reassessed, etc. But for now (i.e., for etch), I would think it sufficient for the security team to agree that they cannot sanely security support a package. I don't think we need a well established process for this, at least anything more than consensus within the security team. Filing the bug means that this is public knowledge, and gives developers a chance to volunteer to assist the security team for these difficult packages. I'd suggest a mail to d-d-a by the security/release teams that announce the first set of packages, so developers aren't surprised when their favorite package drops. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
