Developer Area/Security Team
From Mahara Wiki
< Developer AreaRevision as of 16:17, 11 May 2011 by WikiSysop (Created page with "Here is a description of the rules and procedures that the [https://launchpad.net/~mahara-security/+members security team] follows. <div id="section_1"> ===Guiding principles==…")
Revision as of 16:17, 11 May 2011 by WikiSysop (Created page with "Here is a description of the rules and procedures that the [https://launchpad.net/~mahara-security/+members security team] follows. <div id="section_1"> ===Guiding principles==…")
Here is a description of the rules and procedures that the security team follows.
- Above all else, we need to protect Mahara users to the best of our ability.
- We keep security vulnerabilities secret until a fix is released.
- Before fixes are released, we only share details of security flaws with people involved in releasing fixes.
- Once fixes are public, we release details of the flaws (i.e. full disclosure) but we do not provide exploit code which makes it easy to exploit unpatched sites.
- We release security fixes as soon as possible, balancing the urgency/severity of a problem as well as the frequency of updates for site admins. Therefore we may "sit" on non-critical and non-public issues for a short time in order to include them as part of a larger security update.
- If the details of a security issue are made public before a fix is released, we can unhide the relevant bugs but we must release a fix as soon as possible (i.e. we cannot sit on those ones).
Here's roughly what we do when we receive notice of an unpublished security flaw:
- We review/test the report to confirm that it is a problem and create a private security bug on Launchpad.
- We acknowledge receipt of the problem to the reporter and ask them to keep it quiet while we release a fix for it (we also ask how they want to be credited with the discovery of this problem).
- We fix the problem on:
- the supported stable releases (i.e. the last two)
- the versions of the mahara package in Debian and Ubuntu
- The fixes are not reviewed through gerrit or committed to the bug tracker. Instead, they are attached as patches to the private bugs on Launchpad.
- The fixes are reviewed by another developer manually.
- We request CVE numbers for each separate issue from [email protected]
- Mahara advisories (for the security forum) are prepared.
- We prepare, test and update Debian packages for oldstable and stable and submit them to the embargoed security queue.
- Once everything is ready, we run through the release process. This starts with the fixes being submitted through gerrit (marked as "verified +1" "code review +2" by the submitter) and ends with official announcements.
- The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad.